MCP vs function calling 2026: how they differ and what to choose

# Anthropic Messages API, tool use
import anthropic

client = anthropic.Anthropic()

tools = [{
    "name": "get_weather",
    "description": "Текущая погода в городе",
    "input_schema": {
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "Название города"}
        },
        "required": ["city"]
    }
}]

resp = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "Какая погода в Москве?"}],
)

# resp.stop_reason == "tool_use" -> модель просит вызвать инструмент
for block in resp.content:
    if block.type == "tool_use":
        print(block.name, block.input)  # get_weather {'city': 'Москва'}

// MCP-сервер на TypeScript (@modelcontextprotocol/sdk)
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "weather", version: "1.0.0" });

server.tool(
  "get_weather",
  { city: z.string().describe("Название города") },
  async ({ city }) => {
    const data = await fetchWeather(city);
    return { content: [{ type: "text", text: JSON.stringify(data) }] };
  }
);

await server.connect(new StdioServerTransport());
// Теперь этот сервер видят Claude Desktop, Cursor, ваш агент — без переписывания

MAIN MISCONCEPTION: IT'S NOT «EITHER-OR»

The most common mistake in the 2026 debates — thinking you must choose one over the other. In fact, when an MCP host receives a tool list from the server, it converts them into the very same tool definitions and passes them to the model via native function calling. That is, under the hood MCP always uses tool use.

The difference is purely where the tool definitions come from and who executes them:

1. Bare function calling: schemas are hardcoded in the app, execution is manual.
2. MCP: schemas arrive via protocol from an external server, execution — via a standard client.

Therefore the correct question is not «MCP or function calling», but «should I move tools to MCP servers or keep them inline».

WHEN TO USE PURE FUNCTION CALLING

• One project, 2–5 tools. MCP wrapper here is overengineering.
• Tools are specific to this app and will be useful nowhere else.
• Strict latency requirements. An extra server process and IPC add milliseconds and failure points.
• Prototype or demo. Speed matters more than portability.
• Serverless without long-lived processes, where spinning up a stdio server is inconvenient.

According to practitioners, for 70% of simple integrations plain tool use is enough, and there's no need to build a protocol.

WHEN MCP IS NEEDED

• Several apps/agents share the same integrations. Wrote an MCP server for Jira once — plugged it into IDE, chatbot, and CI agent.
• A ready ecosystem is needed. There are already hundreds of servers for GitHub, Postgres, Slack, filesystem, browser — just take and plug in.
• The client is not your product. If users work via Claude Desktop, Cursor, Zed, or another MCP-compatible host, MCP is the only way to give them tools.
• Division of responsibility in the team. One team builds the server, another the agent, the contract between them is fixed by the protocol.
• Besides functions, resources and prompts are needed — MCP provides both context files and prompt templates, which plain function calling cannot do.

New MCP servers and tool-use frameworks come out in batches — fresh releases are easy to track in REDDYX catalog, so you don’t build an integration that already exists.

PRACTICAL SELECTION STRATEGY FOR 2026

Working algorithm I use on real projects:

1. Start — always with function calling. Describe tools inline, verify the model calls them correctly, catch bugs in the schemas.
2. Notice you’re copying the same schemas into a third project — that’s the trigger to move them to an MCP server.
3. Targeting external hosts (IDE, desktop clients) — go straight to MCP, no way back.
4. Hybrid is legal and normal. Part of the tools via MCP servers, part as inline functions in the same agent. The model doesn’t distinguish them.

Separately on security: an MCP server is executable code with access to your data. In 2026 the community has repeatedly caught problems with untrusted servers (prompt injection via tool descriptions, substitution of tool results). Run servers only from trusted sources and isolate privileges. Curated tool lists and breakdowns of findings we regularly publish in REDDYX catalog.

WHAT ABOUT PERFORMANCE AND PRICE

Technically, MCP does not change the cost of a request to the model — tokens for tool definitions and results are counted the same, regardless of whether the tools come inline or via the protocol. The only overhead of MCP is the network/IPC round-trip to the server, usually a few to tens of milliseconds for local stdio.

A finer point: the more tools you give the model, the more tokens in the system context and the higher the chance that the model will pick the wrong tool. According to community observations, selection quality noticeably drops after several dozen tools in a single context — this applies equally to MCP and raw function calling. It is remedied by grouping servers and loading tools by relevance, rather than dumping everything at once.

If you want to stay on top of things — new MCP servers, tool-use frameworks, and agent tools for AI/ML/Web3 I break down hot off the press in the REDDYX AI Telegram channel — new repositories every 30–60 minutes.