Model Context Protocol

The Model Context Protocol is a JSON-RPC contract that lets a model client call tools, read resources and fetch prompts from a server it did not have to be built against. Connect implements revision 2026-07-28 at POST /mcp over Streamable HTTP, with ten public documentation tools that need no credential and touch no workspace data.

Status: Reference What this means
Audience: developer
Last verified: 2026-09-10
Product version: 6.3.2

The problem MCP solves#

Before a shared protocol, every model client integrated every data source by hand: an adapter per client per source, rewritten whenever either end changed. MCP replaces that with one interface. A server declares what it offers — tools, resources, prompts — in a fixed shape, and any conforming client can discover and call them without prior knowledge of the server.

That is the whole idea, and it is worth being clear about its limits. MCP does not decide what a tool is allowed to do, does not authenticate anybody by itself, and does not make a bad tool description safe. It standardises the conversation, not the judgement.

What revision 2026-07-28 changed#

This revision is why Connect's server is not a copy of an older example. Three changes matter to anyone writing a client.

Protocol-level sessions are gone. Mcp-Session-Id is never minted and is ignored on the way in. A client that expects to be handed a session id by initialize and to quote it afterwards works anyway, because nothing checks it.
The standalone GET stream is gone. Streams are not resumable, so Last-Event-ID is ignored too. Connect answers GET /mcp and DELETE /mcp with 405 and an Allow: POST header.
Every request carries its own metadata. The protocol version and client info travel in params._meta under the io.modelcontextprotocol/ keys, mirrored into the MCP-Protocol-Version, Mcp-Method and Mcp-Name headers — and a header that disagrees with the body is rejected with -32020.

That last rule reads like pedantry until you picture the deployment it protects: a load balancer routing on the header while the server executes the body. If the two can differ, the thing that decided where a request went and the thing that ran it saw different requests. Connect checks all three headers and refuses the mismatch.

POST /mcp HTTP/1.1
Host: connectbyjbrh.com
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_public_docs

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search_public_docs",
           "arguments":{"query":"held draft"},
           "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}

Does Connect use MCP?#

Yes — as a server, in production, at POST /mcp. The endpoint speaks revision 2026-07-28 and also accepts the earlier initialization-based revisions 2025-11-25, 2025-06-18 and 2025-03-26, because refusing them would mean the connector directories of the day could not reach Connect at all.

Ten tools are published, all read-only: search_public_docs, fetch_public_doc, list_capabilities, get_capability, get_workflow, search_glossary, get_technology, get_protocol, get_product_status and get_changelog. Every one reads the same generated documentation corpus the website serves. None of them needs a credential, and none can see a workspace.

What is deliberately absent is as informative as what is present. There is no tool that runs SQL, no tool that proxies an arbitrary internal route, and no write path that bypasses the service owning the record. Connect is not an MCP *client*: it does not connect out to other people's MCP servers.

Limits worth knowing before you build#

Limit	Value	What happens at the edge
Rate	120 calls per minute per client address	`429`, with the limit stated in the error message
Body size	256 KB	`413`, before any parsing
Batching	Not accepted	One JSON-RPC message per request; a JSON array is refused
Origin	Validated when present	`403` for an unrecognised browser origin; absent Origin is fine
Notifications	Accepted	`202` with no body, per the transport

An unknown method returns -32601, unknown parameters -32602, and an internal fault -32603 with a message that names no internal path. A tool that fails for an ordinary reason — an empty query, a page that does not exist — returns a normal result with isError: true rather than a JSON-RPC error, which is the distinction the specification draws between a protocol failure and a tool failure.

Questions#

Do I need an API key to use Connect's MCP server?

Not for the public documentation tools. They read generated files that are already on the public website, so requiring a credential would protect nothing. Anything that reaches a workspace is a different surface with a different authentication story — see Authenticating to the MCP server.

My client sends Mcp-Session-Id and gets no session back. Is that a fault?

No. Revision 2026-07-28 removed protocol-level sessions, so the header is ignored and none is ever minted. Clients written against an older revision keep working because nothing depends on the value.

Why does GET /mcp return 405 when other MCP servers stream on it?

Because those servers implement an earlier revision. The standalone GET stream was removed in 2026-07-28. Returning 405 with Allow: POST tells a client immediately, rather than leaving it holding a stream that will never carry a message.