Claude API Model Context Protocol Support Guide

Does the Claude API support Model Context Protocol?

Short answer: Model Context Protocol (MCP) is a client-side integration standard, not a parameter you pass to the Messages API. Claude Desktop and Claude Code connect to MCP servers directly, and Anthropic has been extending some MCP connector functionality into the API as a beta feature for referencing remote MCP servers in a request. But if you're building against the raw Claude API today, the practical path is to bridge MCP tools into the API's existing tools parameter yourself — which is straightforward once you understand how the two systems map onto each other.

This matters because a lot of developers assume MCP support means "flip a switch and Claude can use any MCP server." In reality, MCP defines how a client discovers and calls tools/resources exposed by a server; the Claude API's tool-use mechanism defines how Claude decides when to call a tool and what to do with the result. You still need something in the middle translating one into the other, unless you're using a client that already speaks MCP natively.

What MCP actually is

Model Context Protocol, open-sourced by Anthropic in late 2024, standardizes how AI applications connect to external context: databases, file systems, APIs, internal tools. An MCP server exposes:

• Tools — callable functions with a JSON schema, similar to Claude API tool definitions
• Resources — readable data (files, records, query results)
• Prompts — reusable prompt templates

An MCP client (Claude Desktop, Claude Code, or a custom app) discovers what a server offers and calls it during a conversation. The protocol is transport-agnostic — it works over stdio for local servers or HTTP/SSE for remote ones.

The key design goal: instead of writing a custom integration for every tool per every AI app, you write one MCP server and any MCP-compatible client can use it.

Where the Claude API fits

The Messages API doesn't run an MCP client loop for you. When you call /v1/messages, you pass a tools array with JSON Schema definitions, Claude decides whether to invoke one, and you get back a tool_use block that you execute yourself and feed back as tool_result. This is functionally similar to what an MCP client does when it calls an MCP server tool — the shapes are close enough that converting between them is mostly mechanical.

If you're already running MCP servers for Claude Desktop or Claude Code and want the same tools available through the API (for a backend service, a Slack bot, a batch job), you have two options:

1. Write a thin bridge that lists tools from your MCP server(s), converts their schemas into the API's tools format, and routes tool_use calls back to the MCP server.
2. Use Anthropic's beta remote MCP connector where available, which lets certain API requests reference a remote MCP server URL directly instead of you writing the bridge. Check current API docs for availability and supported models before relying on this in production, since beta connector features change.

For most teams, the bridge approach is more predictable because it doesn't depend on beta status and works with any provider serving the Messages API format — including SubToAPI, since it exposes the same request/response shape.

Building a minimal MCP-to-API bridge

The MCP SDK gives you listTools() and callTool() against a server. Converting to Claude's tool format looks like this:

import { Client } from "@modelcontextprotocol/sdk/client/index.js";

// mcpClient already connected to your MCP server
const { tools: mcpTools } = await mcpClient.listTools();

const claudeTools = mcpTools.map((t) => ({
  name: t.name,
  description: t.description,
  input_schema: t.inputSchema, // MCP and Anthropic both use JSON Schema
}));

const response = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.SUBTOAPI_KEY}`,
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 1024,
    tools: claudeTools,
    messages: [
      { role: "user", content: "What's the status of order #4821?" },
    ],
  }),
});

const data = await response.json();
const toolUse = data.content.find((b) => b.type === "tool_use");

if (toolUse) {
  const result = await mcpClient.callTool({
    name: toolUse.name,
    arguments: toolUse.input,
  });
  // feed result back as a tool_result in the next request
}

Because the input schemas already overlap, most of the work is in the tool_use → callTool → tool_result loop, not schema translation. If you support multiple MCP servers, namespace tool names (e.g. crm.lookup_order, files.read) to avoid collisions when merging their tool lists.

Practical considerations

• Statelessness: the Messages API is stateless per request — you resend the full conversation each turn. MCP servers can be stateful (open file handles, live connections). Keep the MCP session alive on your server side, not per API call.
• Streaming: if you're streaming responses via SSE (see /docs/streaming), tool-use blocks still arrive as discrete content blocks within the stream — buffer them before calling out to your MCP server.
• Security: MCP servers often have real filesystem or database access. When bridging to a hosted API, restrict which tools are exposed per request rather than dumping every registered MCP tool into every call — Claude's tool selection isn't a security boundary.
• Resources vs tools: MCP resources (readable context, not callable functions) don't map directly to the API's tools parameter. If you need resource content in-context, fetch it yourself and inject it into the user or system message before the request.

If you're routing this kind of traffic through SubToAPI, the setup is the same Messages API surface documented at /docs/messages and /docs/tools, with application-scoped keys (sub_live_...) so each internal service or MCP bridge can have its own key, usage tracking, and rate limits without sharing a root credential. Get a key from /signup and check /pricing for team seat options if multiple services need separate keys.

FAQ

Does the Claude API accept MCP server URLs directly as a request parameter? Not as a stable, generally available feature. Anthropic has beta connector functionality in some API contexts for remote MCP servers, but the reliable, broadly supported path is bridging MCP tool calls into the standard tools parameter yourself.

Is MCP the same thing as Claude's tool use? No. Tool use is the API mechanism for Claude to request a function call and receive a result. MCP is a protocol for how a client discovers and calls tools/resources across different servers. They're complementary — MCP servers can be exposed to Claude through the tool-use mechanism.

Do I need MCP to use tools with the Claude API? No. You can define tools directly with the tools parameter and input_schema without any MCP server involved — see /docs/tools. MCP is useful when you already have reusable MCP servers (for Claude Desktop, Claude Code, or other clients) and want the same integrations available through API calls.