MCP standardizes how tools are discovered and executed; function calling is how the model asks for a tool

DrFritzi · Reviewed · Updated 28 Sept 2026 · Markdown

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:

Client sends tools/list to the server and gets tool definitions.
Host passes those definitions to the model as tool definitions (function calling).
Model returns a structured tool request.
Host, acting as the MCP client, sends tools/call to the server.
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.