The idea
Before a standard existed, every tool integration was bespoke: its own schema shape, its own error format, no discovery. MCP fixes the shape of that conversation — a client asks a server what it has, reads typed schemas back, and calls by name. That is the whole value proposition, and it is why Noorle’s gateway surface is an MCP server rather than a REST API of our own design: your tools work with any MCP client, and swapping clients does not mean rewriting integrations.What MCP defines
The specification has several primitives. Noorle implements tools.
A gateway advertises the tools capability and nothing else. If you are building a client against a Noorle gateway, plan for tools only.
A tool, concretely
Every capability you bind — built-in, plugin, or connector — becomes an MCP tool with a name, a description, and a JSON Schema for its input:{namespace}_{tool}, where the namespace comes from the capability row. See Capabilities for how names are formed and why they differ per account.
Noorle’s additions to a tool listing
Two things ride along on a Noorletools/list response that a generic MCP server would not send.
A risk hint. Each tool carries the spec-native readOnlyHint, derived from the tool’s risk tier. Read-tier tools are marked read-only.
An autonomy outcome. A dev.noorle/autonomy entry in _meta tells the caller what would happen if it called that tool right now: allowed, denied, or conditional on arguments. It carries an outcome and no reason — the listing is reachable without authentication on a public gateway, and a reason would leak the account’s policy.
Both are hints. The authoritative decision is made at dispatch, every time.
Transport
Noorle serves MCP over Streamable HTTP. That is the only transport. There is no separate SSE endpoint, no long-polling fallback, and no WebSocket. Responses are delivered astext/event-stream frames on the POST response, which is why a request must accept both application/json and text/event-stream.
See MCP Gateways for the request/response details, protocol-version negotiation, and session posture.
The other direction: MCP as a client
Noorle also consumes MCP. A connector can point at an MCP server — one from the public registry, or your own — and its tools are re-published through your gateway alongside everything else. Outbound MCP connections use Streamable HTTP. There is no stdio execution: servers in the public registry that only ship a stdio transport are filtered out of what Noorle offers. See Connectors.Tool presentation
A gateway with fifty tools is a worse gateway than one with eight, because tool choice degrades as the list grows. Noorle can present the same bound tools in four different ways — every tool listed directly, three discovery meta-tools, one natural-language dispatcher, or an automatic choice between the first two based on size. See Tool Presentation.Takeaways
- MCP standardizes discovery and invocation; your tools are not locked to one client.
- Noorle gateways implement tools. Not resources, not prompts.
- Transport is Streamable HTTP only.
- A tool listing is per-caller: membership and annotations both depend on who is asking.
Next: MCP Gateways — the endpoint that publishes your tools.