Skip to main content
A gateway is an MCP endpoint you compose. You bind capabilities to it; clients call those capabilities as tools. The gateway holds no conversation and runs no model loop of its own — for that you want an agent.

​
The endpoint

Each gateway gets its own subdomain:
The handle is assigned by the platform when the gateway is created. Find the endpoint on the gateway’s General view in the Portal. Transport is Streamable HTTP only. There is no /sse endpoint and no WebSocket endpoint. A POST must send Accept: application/json, text/event-stream; responses are returned as SSE frames on that POST. A /health route exists on the same origin.

​
What a gateway advertises

ServerCapabilities declares tools and nothing else. Concretely: The advertised protocol-version fallback is 2025-11-25. Newer and older revisions a client asks for are echoed back when the transport recognises them.

​
Configuring a gateway

The gateway’s settings live under five views in the Portal: General, Capabilities, Workflows, Authentication, and Tool Presentation. Per-gateway autonomy policy is edited inside the Tool Presentation view.

​
Capabilities

Bind built-ins, connectors, and plugins. Two rules shape what a client sees:
  • Exposure scope. Each built-in declares which surfaces it may appear on. Computer is agent-only and never appears on a gateway. Plugin Builder, Skill Builder, and Workflow Builder are agent and MCP but not workflow. Everything else is available on all three.
  • Workspace anchoring. Files (all tools), Sandbox (all tools), and Browser’s screenshot, pdf, and snapshot need a workspace to write into. The platform derives that workspace from the gateway plus the authenticated user — never from a client-supplied header. An anonymous caller on a public gateway has those tools withheld from tools/list and from the discovery corpus, so they are not callable by name either.
Because membership and annotations both depend on who is calling, tools/list responses are marked cacheScope: private with ttlMs: 300000. Two callers on the same gateway can legitimately get different lists.

​
Workflows

Workflows attached to a gateway appear as tools on that gateway. This is the one system-tool surface live on the MCP surface — skills, journal search, scheduling, and form rendering are all agent-only.

​
Authentication

Three modes: Credentials go in Authorization: Bearer <token>. Two token shapes are accepted and disambiguated by prefix:
  • ak-… — a Noorle API key. It must belong to the gateway’s account and hold Read on this gateway.
  • eyJ… — a JWT minted by this gateway’s own authorization server.
There is no X-API-Key header on a gateway. That header is a management-API convention only.
Each gateway origin is its own OAuth authorization server. It serves /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, /oauth/authorize, /oauth/token, and /oauth/register (plus /authorize, /token, /register aliases for clients that skip discovery). A token minted for one gateway does not validate at another — the audience carries that gateway’s resource URN. Supported grants are authorization_code, refresh_token, and client_credentials; PKCE is S256 only. Human consent for /oauth/authorize hands off to the Portal. If the account has no spendable balance, an authenticated request is rejected with 402 Payment Required before reaching a tool.

​
Tool presentation

Controls what tools/list returns. The platform default is Adaptive. See Tool presentation for the four modes.

​
Autonomy on a gateway

An MCP gateway is an unattended surface: there is no channel on which to ask a human. A call that would pause for approval is denied with reason non_interactive_surface — it does not prompt and it does not queue. Each listed tool carries a readOnlyHint and a _meta entry dev.noorle/autonomy with the outcome the gate would produce for that caller. The annotation is a hint; the gate re-evaluates at dispatch and can still deny. See Autonomy and approvals.

​
Limits

Pagination is opt-in. A tools/list that carries no pagination parameters comes back complete in one response, however many tools the gateway exposes; the 50-tool page only applies once a client starts paging. Anonymous callers are keyed on peer IP rather than sharing one bucket. Both limiters are fixed 60-second windows and both fail open if Redis is unreachable. Exceeding the request rate returns JSON-RPC error -32029 with {code, limit, window_secs} in data. Exceeding the handshake rate returns HTTP 429 with Retry-After: 60 — it happens before the request becomes a JSON-RPC exchange.
Noorle emits no X-RateLimit-* headers on any surface. Retry-After on the handshake 429 is the only rate-limit header you will see.

​
Sessions

Which session posture a gateway uses is picked by the transport from the client’s protocol revision, not by configuration. Clients on 2026-07-28 and later are served statelessly and receive no Mcp-Session-Id. Older-lifecycle clients keep a session record. Either way the handler holds no per-session state, and the client-supplied Mcp-Session-Id is never used to select a workspace.

​
Next