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 has one configuration fact that fails in a genuinely confusing way.

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" }
  ]
}

Be honest about what you know here. The exact selector fields on mcp_toolset are something to check on the day. What is not up for debate is that both objects have to be present and have to line up. Memorise the requirement, look up the field names.

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 honest note about how you would confirm this on the day, because it changes where you look. There is no sentence in the docs that says "strict is unsupported on MCP tools". The evidence is an absence: the strict tool use page places strict on a tool definition alongside name, description and input_schema and never mentions MCP, and the connector's own per-tool configuration table lists exactly two fields, enabled and defer_loading. So if a question sends you looking for a quotable prohibition you will not find one and you will burn time. Check the mcp_toolset field reference instead and read what is not in it.