Skip to content
Clawdemy

Summary: Model Context Protocol

The cross-provider tool layer. Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems, governed at modelcontextprotocol.io and supported across a range of AI applications and developer tools (Claude, ChatGPT, Visual Studio Code, Cursor). Three capability types per server: tools, resources, prompts. The MCP connector is the Messages API feature that lets Claude talk to remote MCP servers directly, without your application running an MCP client. Verbatim from the docs: Claude’s Model Context Protocol (MCP) connector feature enables you to connect to remote MCP servers directly from the Messages API without a separate MCP client. Request shape: mcp_servers array (each entry: type: “url”, url HTTPS, name, optional authorization_token for OAuth) plus mcp_toolset entries inside the tools array (each picks a server by mcp_server_name and configures tools via default_config + configs). Beta header mcp-client-2025-11-20; the earlier mcp-client-2025-04-04 is deprecated. Every server must be referenced by exactly one toolset. Per-tool flags: enabled (default true) and defer_loading (pairs with tool_search from lesson 5). Response shape: mcp_tool_use + mcp_tool_result blocks inline in the same response (same no-round-trip-in-your-code property as lesson 5’s server tools). Decision frame across the three tool layers: custom client tool (L4) when the logic is yours; server tool or Anthropic-schema client (L5) when Anthropic already provides the capability; MCP connector (L6) when the capability lives in a third-party catalog that speaks MCP. Active limits: tools only (not resources or prompts via connector); HTTPS transports only (no local STDIO); not on Amazon Bedrock or Vertex AI; not ZDR eligible; OAuth is your job. For limits you cannot work around, use the TypeScript client-side helpers with your own MCP client. Lesson 7 (prompt caching + context management) makes a request that mixes custom + Anthropic + MCP tool definitions affordable to repeat.

Core ideas

Section titled “Core ideas”
  • MCP is an open standard, not Anthropic-proprietary. Governed at modelcontextprotocol.io; supported across Claude, ChatGPT, VS Code, Cursor, others. Three primitive types: tools, resources, prompts. USB-C-port analogy: one standardized connector, many hosts and devices.
  • The MCP connector lets Claude talk to remote MCP servers directly from the Messages API; no MCP client in your code. Currently supports tool calls only (resources and prompts require the client-side TypeScript helpers).
  • Request shape: mcp_servers (URL + OAuth) + mcp_toolset in the tools array (per-server config). Beta header mcp-client-2025-11-20. One mcp_toolset per server, mandatory pairing.
  • Per-tool configuration: enabled (default true) + defer_loading (default false; pairs with tool_search). Three patterns: allowlist (default off + enable specific), denylist (default on + disable specific; recommended for read-only assistants), mixed.
  • Response blocks: mcp_tool_use (model’s call with server_name + input) and mcp_tool_result (connector-executed result with tool_use_id + content + is_error). Same array as lesson 1’s text blocks, lesson 4’s tool_use, lesson 5’s server_tool_use; no round-trip in your code (like server tools).
  • Decision frame: custom client tool (L4) for your domain logic; server tool or Anthropic-schema client tool (L5) for capabilities Anthropic provides; MCP connector (L6) for capabilities in someone else’s catalog that already speaks MCP. Most production apps mix all three.
  • Cross-provider value: integrate with an MCP server once and the integration survives a model-provider swap; expose your own tools as an MCP server and any MCP-capable host (Claude, ChatGPT, VS Code, Cursor) can use them. The spec home page calls this “build once and integrate everywhere.”
  • Active limits: tools only via connector; HTTPS transports only (no local STDIO); not on Amazon Bedrock or Vertex AI; not ZDR eligible; OAuth is your responsibility. The TypeScript client-side helpers (mcpTools, mcpMessages, mcpResourceToContent, mcpResourceToFile) handle the cases the connector cannot.
  • Where it fits: Phase 2 third lesson. L4 = your tools, L5 = Anthropic’s tools, L6 = everyone else’s tools, L7 (next) = make a mixed stack affordable via prompt caching.

What changes for you

Section titled “What changes for you”

Before this lesson, your tool inventory was the union of what you wrote (L4) and what Anthropic provides (L5). After this lesson, the third lane is open: any third-party MCP server is reachable from Claude through the connector with a few JSON keys instead of a per-vendor SDK. The highest-leverage move this week: take one existing third-party integration in your application (a calendar, a project tracker, an internal data platform) and check whether the vendor or the community ships an MCP server; if so, replace your custom integration with the connector and remove the vendor-specific client code. The second-highest: when you next write a tool that you want to share with teammates or expose beyond your own application, write it as an MCP server rather than a per-application library; any MCP-capable host can then use it, and your tool surface becomes portable across AI applications. For regulated workloads where ZDR matters today, the connector is not the right path yet; use the TypeScript client-side helpers with a self-hosted MCP client (or stick to L4 custom tools and the ZDR-eligible L5 server tools) until the connector’s data-retention posture changes. Lesson 7 (next) makes a request that surfaces tool definitions from L4 + L5 + L6 cacheable, which is what keeps a real production application’s tool overhead from compounding over long sessions.