MCP servers

Model Context Protocol (MCP) servers let your agents call tools that live outside Quant — your CRM, an internal service, a third-party API that already exposes an MCP endpoint. Register a server against your organisation, attach it to the agents that should use it, and its tools appear alongside the built-in ones.

All traffic passes through the Quant MCP gateway. The gateway is where your credentials are injected, where egress is controlled, where tool schemas are pinned, and where every call is audited.

Why a gateway

The obvious way to connect an agent to a remote MCP server is to hand the agent the credentials and let it connect directly. That approach has three problems, and the gateway exists to solve all three.

Credentials would reach the client. A developer running QuantCode on a laptop would hold your CRM token. So would anything else on that laptop. The gateway holds the credentials instead and injects them server-side, so they never leave Quant infrastructure.

A server can change its tools underneath you. An MCP server you trusted last week can silently alter what its tools claim to do — the “rug pull”. Because tool descriptions become part of the model’s instructions, that is a prompt-injection vector. The gateway hashes the tool list and detects when it changes.

Arbitrary URLs are an SSRF risk. You supply the server URL, and Quant fetches it from inside our network. The gateway blocks private, reserved, and link-local address ranges, and re-validates on every redirect hop.

The MCP specification is explicit that a client’s token must never be relayed downstream. Passing it through would break audience binding and destroy audit attribution. The gateway never does this.

How it fits together

Your agent  ─┐
QuantCode   ─┼──►  MCP gateway  ──►  your registered MCP server
Workflows   ─┘     (injects org
                    credentials)

The gateway terminates MCP Streamable HTTP requests from two caller classes — platform-internal callers such as the server-side agent loop, and end-user callers such as the QuantCode CLI with an org-scoped token. Both take the same enforcement path.

What the gateway does per request

1. Resolves the registration for your organisation.
2. Checks governance — your organisation’s AI configuration must permit the call.
3. Injects credentials for the downstream server, fetched from Secrets Manager. For OAuth client credentials it runs the flow and caches the token.
4. Guards egress — HTTPS only, with private and reserved ranges blocked and every redirect hop re-validated.
5. Enforces the tool allowlist at both the server level and the per-agent attachment level.
6. Checks the schema pin over the full downstream tool list, before allowlist filtering.
7. Audits the call, with hashed arguments.

Supported protocol versions

The gateway speaks 2025-11-25 toward callers and negotiates with the downstream server, so neither side has to match the other. It supports Streamable HTTP servers from spec version 2025-03-26 onward, including servers that use sessions.

Only remote servers reachable over HTTPS are supported. Servers that speak stdio must be wrapped in an HTTP transport first.

Limits

Limit	Value
Downstream request timeout	30 seconds
Overall gateway budget	50 seconds
Transport	Streamable HTTP only
JSON-RPC batching	Not supported — send single requests
Response format	application/json (the gateway does not stream toward the caller)

Next steps

• Register a server — add a server, test the connection, and attach it to an agent
• Security model — credential handling, schema pinning, and egress controls in detail