# MCP standardizes how tools are discovered and executed; function calling is how the model asks for a tool > Function calling and MCP work at different layers: function calling is the model API feature by which a model requests a tool call, while MCP is the protocol by which a client finds and runs tools on a server, and an MCP host typically uses both. ## Answer Function calling (also called tool use) is a model API feature: your application sends tool schemas to the model, the model returns a structured request to call one, and your code runs it. MCP is a protocol between a client and a server: the server owns the tool schema and the execution, and the client discovers tools at runtime with `tools/list` and runs them with `tools/call`. They are not alternatives. An MCP host still needs the model's tool-calling to let the model choose a tool. Checked against MCP specification **2026-07-28** on 2026-09-28. ## Details ### Two layers in one call Function calling is the model-facing layer, and MCP is the tool-facing layer. Anthropic's tool-use docs describe the first: Claude returns a `tool_use` block, and for client tools your application executes it and sends back a `tool_result`. The MCP tools spec describes the second, and its message-flow diagram has the LLM selecting a tool, the client sending `tools/call` to the server, and the client passing the result back to the LLM. Sequence for one call in an MCP host: 1. Client sends `tools/list` to the server and gets tool definitions. 2. Host passes those definitions to the model as tool definitions (function calling). 3. Model returns a structured tool request. 4. Host, acting as the MCP client, sends `tools/call` to the server. 5. Server returns a result. The host feeds it back to the model. Anthropic's MCP connector (a beta feature when checked) handles this inside the API for remote servers: you list servers and an `mcp_toolset` in the request, and Claude's calls appear as `mcp_tool_use` blocks. That the host maps MCP tools onto the provider's tool feature is an inference from these docs, not spec text. The connector supports only tool calls, and only servers reachable over HTTP. ### Decision table | Situation | Choose | |---|---| | 2-3 tools used inside one application | Plain function calling. A server adds no benefit | | Tools reused by many clients or hosts | MCP server | | An existing REST API you own | Wrap it as an MCP server, or use both: keep the API and add a thin server | | Tools that must be found at runtime | MCP: clients call `tools/list` | ### Specific MCP behavior - `tools/list` results carry `ttlMs` and `cacheScope`, so clients can cache them. Servers SHOULD return tools in a deterministic order. - A tool that fails while running returns `isError: true` in the result, so the model can retry. An unknown tool or malformed request is a JSON-RPC error instead. ### MCP versus a plain REST API A REST API is not required to describe itself in a form a model can use, so each client needs its own glue. An MCP server publishes typed tools: each has a `name`, a `description` and a JSON Schema `inputSchema`, listed by `tools/list`. Any MCP client can use them through one protocol. The premise that MCP needs a long-lived session is outdated: specification 2026-07-28 states that MCP is stateless and that each request carries what the server needs. See [[mcp-2026-07-28-changes]]. ### Common mistakes - Treating MCP as a replacement for the model's tool-calling. It is not. - Building an MCP server for two tools in a single app. - Copying older articles that describe sessions and an `initialize` step as required. - Returning protocol errors for bad input that the model could fix. The spec puts input validation errors in `isError: true` results. ## See also - [[mcp-tools-resources-prompts]] - [[mcp-json-rpc-format]] - [[what-is-mcp]] - [[mcp-too-many-tools-context-bloat]] ## Sources - [MCP Specification 2026-07-28 — Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) - [MCP Specification 2026-07-28 — Caching](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching) - [MCP Specification 2026-07-28 — Overview](https://modelcontextprotocol.io/specification/2026-07-28/basic/index) - [Claude API docs — Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) - [Claude API docs — MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) ## Sources - [MCP Specification 2026-07-28 — Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) - [MCP Specification 2026-07-28 — Caching](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching) - [MCP Specification 2026-07-28 — Overview](https://modelcontextprotocol.io/specification/2026-07-28/basic/index) - [Claude API docs — Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) - [Claude API docs — MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector)