The MCP connector, and its two-part requirement

MCP is the Model Context Protocol: a standard way for a server to publish capability so any client can use it, instead of every integration being bespoke. The connector is how a Messages API request reaches one of those servers.

Tools and MCPs is 10.6% of the paper. Most of that is tool implementation, which you already have. This lesson is the connector, and it turns on one configuration fact that the API checks for you.

Both objects, or nothing

A working MCP call needs two things in the request, and they work together:

An mcp_servers entry. This declares the connection: where the server lives and how to authenticate.

A matching mcp_toolset. This exposes tools to the model.

{
  "mcp_servers": [
    {
      "type": "url",
      "url": "https://example.com/mcp",
      "name": "my-server"
    }
  ],
  "tools": [
    { "type": "mcp_toolset", "mcp_server_name": "my-server" }
  ]
}

Be honest about what you know here. The per-tool selector fields inside default_config and configs are something to check on the day. What is not up for debate is that both objects have to be present and that mcp_server_name has to match a declared server. Memorise the requirement, look up the rest.

The header, and the dead header

Current: mcp-client-2025-11-20.

Deprecated: mcp-client-2025-04-04.

The old one shows up in blog posts, in Stack Overflow answers, and in your own repo from earlier in the year. Seeing 2025-04-04 in a snippet is a dating signal, the same way thinking.type was in Module 2. Treat the whole snippet as old, not just that line.

Why the split exists

It looks like ceremony until you name the two concerns.

You have already built this distinction, more than once, without calling it that. A database connection string is not a query. Installing a package is not importing a symbol from it. In both cases the expensive, credentialled, infrastructure-shaped step is separate from the cheap per-use decision about what you actually want right now, and nobody would want them fused.

mcp_servers is connection: address and auth, the expensive-to-set-up part. mcp_toolset is exposure: what this particular request puts in front of the model.

Separating them means you can connect to a server with forty tools and expose four of them on a request where only four are relevant. Every tool definition you expose costs context on every single turn, so exposing everything a server has, on every call, is a real bill and a real distraction for the model. Connection is a fact about your infrastructure. Exposure is a decision per request.

The gap you already met

Recap, because it is the seam between two exam domains: strict is not available on mcp_toolset.

So moving a tool out of your own definitions and into an MCP server is not a pure refactor. You lose strict tool use in the process, and nothing in the diff will tell you.

One note on where to confirm this on the day, because it is not where you would look first. The strict tool use page places strict on a tool definition alongside name, description and input_schema and never mentions MCP at all, so reading that page leaves you inferring from silence. The quotable sentence is on the Tool reference page, in the table of optional tool definition properties: the strict row’s “Available on” column reads “All tools except mcp_toolset”. One row, explicit, and it also tells you allowed_callers is excluded on mcp_toolset for the same reason.

Worth knowing that the Tool reference is where this class of fact lives generally. It is the page that carries the type strings, the GA-versus-beta status, the client-versus-server execution column, and which optional properties each tool accepts. If a question is about a property rather than a behaviour, go there first.