Would it be worth routing these through the config framework in org.apache.asterix.common.config instead of reading them as raw system properties? Everything else in the tree goes through there, and you would pick up cc.conf support, validation, and the generated docs for free. ExternalProperties is probably the closest existing example to model this on.

Not a blocker for the functionality, but it is the kind of thing that is much cheaper to do now than after someone starts depending on the property names.

Minor custody point, specific to the token rather than the other two properties.

If an operator supplies this as -Dasterix.mcp.gateway.token=... on the JVM command line, which is the obvious way to set a system property, the value is visible in the process list to any local user. A property set programmatically at startup would not be, so this depends on how it gets populated rather than being inherent to System.getProperty.

Since you may be moving the other two to the config framework anyway, routing the token through the existing configuration mechanism at the same time would sidestep the question entirely.

Does the gateway use the optional Streamable HTTP GET/SSE channel? If so, this needs a streaming response path.

forward relays through HttpResponse.BodyHandlers.ofByteArray() on line 107, which waits for the complete upstream response before writing anything back. A long-lived SSE connection never completes, so the browser would receive no events at all and the request would sit until the 60 second UPSTREAM_TIMEOUT.

If the gateway is POST-only in practice, then this is fine as written and I would just drop the get() override, or have it return 405 with a short comment saying the streaming profile is not supported yet. Either is much easier to diagnose than a silent one minute hang.

The transport uses DELETE to terminate a session, and there is no delete() override here, so AbstractServlet will reject it.

Worth flagging that the servlet is only half of this. MCPClientService never issues a DELETE either, and disconnect() just dispatches an action that resets local state, so the gateway is never told the session ended. Supporting termination properly needs both a delete() override here and a client-side request carrying the current Mcp-Session-Id before the local state is cleared.

How long orphaned sessions actually live depends on whether the gateway has its own idle timeout, which I cannot see from here. If it does, this is untidy rather than a leak. Also note the spec allows a server to answer DELETE with 405, so the client should treat that as success rather than an error.

This is the one I would most want resolved before merge, and the answer determines how serious it is, so I am asking rather than asserting.

The enabled flag is the only gate visible in this class. Once it is on, the proxy attaches a privileged gateway token to every request that reaches /mcp, without any check on who is asking. That is a confused deputy: the caller supplies no credential, the CC supplies the authority, and the servlet does not verify the caller is entitled to it. The Javadoc reasons carefully about the gateway side of the boundary but says nothing about this side.

So the question is whether the dashboard web server authenticates and authorizes this route somewhere outside this class. If it does, please state that in the Javadoc, because it is load bearing for the whole security argument and the next reader will have the same question. If it does not, then enabling this feature effectively grants gateway access to anyone who can reach the CC's dashboard port, and it needs a check before the token is attached.

Every other dependency in this file is pinned exactly (codemirror: 5.65.18, lodash: 4.17.23, and so on), and these two use caret ranges. Worth matching the convention. To be precise about why: bun.lock is committed, so installs are already reproducible. Pinning here is about following the file's existing convention and avoiding a silent minor or patch bump the next time the lockfile is regenerated.

Separate question while you are here, and not a blocker: could you confirm the generated third-party license inventory picked up DOMPurify and marked, and that their licenses are fine under the project's dependency policy? DOMPurify is Apache-2.0 or MPL-2.0 dual and marked is MIT, so I expect this is fine, but the 3rdpartylicenses.txt regeneration is 1302 lines of churn in this commit and it would be good to know that was a clean regeneration.

This one can just go. DOMPurify has shipped its own type definitions since v3, and @types/dompurify@3.2.0 is a deprecated stub package whose only content is a dependency back on dompurify. Removing it should not change anything at the type level.