When should you choose MCP over simple tool integration?

What you need to know

Signals for MCP

• More than one consumer. Two or more apps (or agents) need the same tools.
• Different owners. The data team owns the warehouse; the agent team should not maintain its query tools.
• Isolation. The tool needs heavy dependencies or secrets you do not want in the agent process.
• Vendor-provided. The SaaS you use already publishes an MCP server — you get the integration for free (after review).
• User-chosen connectors. Your product lets users bring their own tools.

Signals for plain function calling

• One app, few tools. Three functions in the same codebase.
• Tight latency. Each call must add almost nothing; an extra network hop per call matters.
• Tight coupling. The tool touches in-memory app state or transactions that do not make sense as a public interface.
• Critical writes needing custom gates. You can still do this with MCP, but many teams keep money-moving tools native.

A quick decision table

A real-life example

A fintech company is building its first AI assistant for customers. It needs three tools: balance, transactions and transfer. The team debates MCP.

They choose native tools: one app, three functions, strict latency targets, and the transfer tool must run inside the same service as the fraud check. MCP would add a service, a hop and nothing gained.

Six months later, there are four assistants — customer, operations, collections and a developer assistant — and all need the same "customer 360" lookups and policy search. Each team had copied the tool code; the copies disagree on how to mask PAN numbers. Now they build a "customer-context" MCP server owned by the platform team, with one masking rule, OAuth scopes per assistant, and audit logs in one place. The transfer tool stays native in the customer assistant.

That is the realistic pattern: start native, move shared integrations to MCP when duplication hurts.

Follow-up questions to expect

• "Is there a performance cost?" — Small for stdio; for remote HTTP, one network round trip per call plus discovery at start. Usually minor next to model latency, but it adds up in chatty agents.
• "How do you secure a remote MCP server?" — OAuth with narrow scopes, validation of every input, per-user authorisation in the handler, rate limits, and audit logs — the same as any API.
• "Would you use a public MCP server in production?" — Only after reviewing it, pinning its version, and restricting which of its tools the agent may use.