Hi,
I'm building a gateway on the TMS MCP components (AI Studio 1.7.4.1) that fronts several stdio MCP servers, giving each one its own TTMSMCPStreamableHTTPTransport with a distinct MCPEndpoint — /mcp/this, /mcp/that, and so on — all on the same port. That doesn't work, and I think it comes down to a single line.
TMS.MCP.HTTPServer.Win.pas, TTMSMCPWinHTTPServer.StartServer, line 1180:
url := Format('%s://%s:%d/', [protocol, ip, FPort]);
The registered http.sys prefix is the port root, with no path component. Each transport creates its own TTMSMCPHTTPServer, its own server session and its own URL group, so the second transport on a given port calls HttpAddUrlToUrlGroup with a prefix that is already registered and fails with ERROR_ALREADY_EXISTS (183). The first endpoint works; the second never binds.
The transport itself is already path-aware — HandleServerRequest compares ARequest.URI against FMCPEndpoint and 404s anything else — so the path is understood one layer up but never reaches the prefix registration. TTMSMCPWinHTTPServer has no path or UrlPath property at all (only Port, BindingIP, UserGroup), so there's no way to supply one from outside.
Suggested fix: give TTMSMCPHTTPServer/TTMSMCPWinHTTPServer a UrlPath property, have TTMSMCPStreamableHTTPTransport set it from FMCPEndpoint in Start, and build the prefix as:
url := Format('%s://%s:%d%s/', [protocol, ip, FPort, path]);
defaulting to '/' when empty so existing behaviour is unchanged. That would let several endpoints share a port, each with its own URL ACL reservation. One thing worth testing if you do this: http.sys prefixes must end in '/', and I haven't confirmed whether a request to exactly /mcp/logs (no trailing slash) matches a /mcp/logs/ prefix — that matters because agent platforms are typically given the URL without one.
This isn't blocking me — I've moved to one port per backend, which is fine for Streamable HTTP since the client is given a full URL anyway. But the current behaviour is easy to hit and hard to diagnose: the failure surfaces as an http.sys error code from the second transport, with nothing pointing at the shared prefix as the cause. Even if you'd rather not add the property, a clearer exception message there would save the next person some time.
Happy to test a build if that's useful.
Best regards,
Alex