Tools over MCP

Tools over MCP means choosing direct, application-owned tool calls instead of adopting MCP as the default integration boundary when predictability matters more than portability. MCP is a deployment and interoperability choice rather than a prerequisite for capable agents.

Direct tools keep the call path under your application's control, where you own schemas, permissions, retries, tracing, and rollout. MCP adds a portable boundary for capabilities your application does not own, so the decision turns on ownership, execution location, and evaluation variance.

In this guide you will learn:

• What MCP and function calling each control
• Why direct tools produce clearer execution paths and failure modes
• How to test latency, success rates, and regressions
• Why distributed MCP dependencies complicate diagnosis
• When MCP's portability justifies its operational cost
• How to choose direct tools, MCP, or both

Key insights

• Direct tool calls reduce the surfaces you must trace, but they do not replace orchestration or governance.
• A remote MCP server turns a local tool call into a distributed system you have to monitor.
• Evaluation improves when schemas, permissions, and failure labels remain visible to your application.
• Ownership decides the boundary, and when another team runs the service you are describing a fact rather than making a choice.

What is MCP vs function calling?

Function calling describes how a model requests an operation. MCP describes how tools and other capabilities are exposed across a client-server boundary.

Compared as integration boundaries, direct tools and MCP differ on three axes:

A protocol is not an orchestration strategy

A protocol standardizes how systems exchange messages. It does not decide which tool runs first, when a retry is safe, or whether a human must approve an operation.

That work belongs to your agent runtime. You still need state management, branching, retries, compensation logic, and policy checks around MCP.

A direct tool and an MCP tool can both sit inside the same orchestration layer. The protocol changes where the boundary sits, and your runtime still makes every decision.

The client, server, transport, catalog, and execution environment each carry a separate responsibility.

Where authorization and audit actually live

A function schema tells the model which arguments to provide and what result shape to expect. It does not define who may invoke the function, which tenant it can access, or how the call appears in an audit trail.

Your application must add those controls. They include identity propagation, authorization checks, rate limits, data handling rules, approval gates, and version ownership.

MCP distributes them across the client, server, and identity layers. That separation helps with shared ownership, and it creates more places to inspect when behavior changes.

Function calling gives you an invocation mechanism, while MCP gives you an integration boundary.

Why are direct tools easier to predict?

Prediction comes from controlling the execution path. Direct tools keep more of that path in code your team owns and can replay.

Fewer runtime components and clearer execution paths

A direct tool is usually an application function or a thin adapter around a service. Your trace can follow the model decision, argument validation, handler, downstream request, and returned result.

That path can still contain bugs. The difference is visibility: you can instrument the handler, pin its version, and reproduce the failure with the same dependency configuration.

An MCP deployment adds a client library, server process, transport, catalog discovery, remote authentication, and another release cycle. Each component can introduce timeout behavior or state you do not control from the calling application.

The distinction becomes sharper when your team is debugging a production failure. "The model chose the wrong tool" is a different incident from "the server exposed an outdated schema" or "the remote dependency returned a partial result."

Explicit inputs, outputs, and failure modes

Direct tools encourage contracts that live beside the code that enforces them. You can reject malformed arguments before a downstream request, normalize errors at the boundary, and record the exact input that caused the failure.

The contract should cover more than a successful response. Define what a validation failure, a timeout, and a partial result each look like.

The 2024 ICML paper Executable Code Actions Elicit Better LLM Agents reports a success-rate comparison. CodeAct achieved up to 20% higher success rates than widely used alternatives.

That result predates MCP and does not benchmark it directly. It supports a narrower point: giving an agent an executable action format can outperform less direct action interfaces.

That advantage comes from the contract rather than the tool type. Your schemas, error handling, and evaluator still determine whether the action path works.

How can teams evaluate tool performance with confidence?

Evaluation fails when your test cannot tell whether the model, tool contract, authorization state, or dependency caused the result. Each of those needs its own label before a number means anything.

Repeatable tests and measurable latency

Build a harness that records the model request, selected tool, validated arguments, handler duration, downstream duration, and final outcome. Keep those timings separate.

A single total latency figure hides the root cause. A slow model choice, a handler waiting on a service, and an oversized response being transformed all look identical in one number.

Pin tool versions and fixture data for regression runs. Test the same task against valid inputs, malformed inputs, missing permissions, slow dependencies, and empty datasets.

Then add field data from real users and production traces. A passing local test does not tell you how the call behaves when a customer's account has unusual data or a dependency is degraded.

Success rates, error classes, and regression tracking

A useful evaluator records more than pass or fail. Classify failures by model selection, argument construction, validation, authorization, dependency response, timeout, and post-processing.

Those classes point to different owners. A selection error usually points at the description, a validation error at the schema.

An authorization failure points somewhere else entirely: your policy.

Track the same task set across prompt changes, model changes, tool releases, and infrastructure changes. Store the inputs and outputs needed to replay the failure without asking the model to recreate it.

This is the discipline behind building a production AI agent. When your evaluator names the failing layer, your team can fix the root cause instead of tuning prompts around an unknown defect.

Direct tools make evaluation cleaner because the test can observe the contract and the execution path in one place.

Why can MCP behavior be harder to evaluate?

MCP behavior can vary because the model sees more than a function schema. It depends on what the server exposed, what survived discovery, and which identity made the call.

Distributed servers, changing tool catalogs, and remote dependencies

A remote MCP server turns a local tool invocation into a distributed system.

Tool catalogs also change the model's decision surface. Add a similarly named tool and selection changes, or reword a description and the model builds different arguments.

Remove a tool and a previously valid plan becomes a fallback path.

According to Cloudflare's Scaling MCP adoption, routing 52 tools through 2 portal tools cut the tokens spent on tool definitions from roughly 9,400 to roughly 600, a 94% reduction. The post was published April 14, 2026 and modified July 15, 2026.

That number is Cloudflare's own reference architecture, and it measures tool definitions rather than a whole session. It still exposes the operational issue: tool exposure and context design belong in your performance review.

Context, discovery, and authorization variables

A tool can be available to the client but absent from the model's current context. It can appear with a different description after discovery, and the server can return different data for different identities.

That makes a failed run harder to classify. Was the tool unavailable, undiscovered, poorly described, denied by policy, or simply ignored by the model?

Context engineering can also degrade a session over time. Large schemas, intermediate results, and accumulated instructions consume attention, while replacing MCP with direct tools will not fix poor context management by itself.

Treat discovery and authorization as test dimensions. Capture the catalog shown to the model, the identity used for the call, and the server version involved.

The April 13, 2026 revision of Model Context Protocol at First Glance reviewed 1,899 open-source MCP servers. It found general vulnerabilities in 7.2% of them and MCP-specific tool poisoning in 5.5%.

Those findings are a reason to evaluate server behavior alongside the client's final answer.

MCP adds useful reach, but every added boundary becomes another variable your diagnosis must isolate.

When does MCP still earn its operational cost?

MCP earns its place when portability, shared ownership, or remote execution matters more than keeping every tool inside one application.

Two situations account for most of the cases: the capability has to serve more than one client, or someone else owns the service behind it.

Interoperability across clients

Suppose the same capability must serve several agent clients, internal workflows, developer environments, or products. A shared protocol can prevent each client from building a separate adapter and permission model.

That portability has a maintenance cost. You still need version rules, ownership, compatibility tests, access policies, and a clear process for changing tool descriptions.

The right question is not whether MCP is more portable. It is whether portability removes enough repeated integration work to justify another runtime boundary.

AgentBridge, Blazity's open-source API integration framework for agents, can help when many clients need to understand the same business capabilities. The representation must remain precise enough for evaluation and safe enough for production access.

Remote tools, shared ownership, and portable integrations

MCP fits a capability owned by another team or organization. The owning team can expose the server, maintain its service boundary, and publish the contract without embedding its implementation inside your agent.

That arrangement works when the boundary is real. A payments team owns payment operations, and a vendor may own a service you cannot install inside your application at all.

Anthropic's code execution with MCP report, published November 4, 2025, cut one agent's token usage from 150,000 tokens to 2,000 by presenting MCP servers as code APIs. The method loaded only the tool definitions it needed and processed intermediate results in code.

MCP also earns its cost when the tool must execute near protected data or infrastructure. Moving that capability into your application may create a larger security and ownership problem than the protocol boundary creates.

A practical decision framework

Default to direct tools, and reach for MCP when the integration has to travel. The table below sets the three options against what you keep and what you pay.

Direct tools for local control

Use direct tools for core actions that affect money, permissions, account state, or customer-visible workflows. Keep the schema, policy check, handler, and evaluator close together.

If a tool moves money or changes account state, keep it in your codebase until someone gives you a reason it cannot live there.

This choice also fits early production work, where your team is still learning which actions deserve automation. A smaller call surface gives you better findings before you commit to shared infrastructure.

MCP for a traveling boundary

Ownership is the whole test. If another team runs the service, the protocol choice has already been made for you.

Document the server owner, supported clients, authentication path, compatibility policy, failure contract, and deprecation process. If those answers are unclear, the protocol will not solve the organizational problem.

MCP becomes a sensible boundary once ownership already crosses that line. Before it does, you are paying for a boundary you could have owned.

A combined boundary for selected capabilities

A combined design keeps high-risk business actions as direct tools while exposing selected remote capabilities through MCP. The application can present a stable internal contract and translate to the external server where needed.

Start with a small MCP surface. Keep discovery, authorization, and server responses in your evaluation fixtures, and record the external contract separately from the internal one.

This approach lets your agent runtime test its core behavior without requiring every test to depend on a remote server. It also preserves portability where portability has a clear owner and a clear purpose.

Where to start with tools over MCP

Choose direct tools when your application owns the capability and you need tight evaluation. Choose MCP when clients, teams, or deployment boundaries must change independently, then combine both when a stable local core meets portable remote capabilities.

If you need help designing and operating production AI agents, Blazity can map the boundary, build the evaluation harness, and ship the runtime.

FAQ on tools over MCP

These questions come up once a team has to defend the boundary it picked.

Should every new agent use MCP?

No, direct tools are the better default when your application owns the operation. Starting on MCP means paying for discovery, authorization, and transport before you know which actions deserve automation.

Start with the smallest boundary that gives you the control and portability your architecture requires. Add MCP when a real integration constraint justifies it.

Can direct tools call remote services?

Yes, a direct tool can wrap a remote service without exposing that service through MCP. Your application owns the schema, authentication flow, error mapping, retries, and tracing.

That approach keeps the model-facing contract local while allowing execution to happen elsewhere. You give up protocol-level portability across clients.

Does MCP improve agent performance?

MCP can improve agent performance when you control discovery and context exposure. The protocol alone does not fix an oversized schema or a stale catalog.

Measure model selection, context size, tool latency, and final task outcomes together.

What if you already run MCP for tools you own?

Start by measuring which tools your application actually needs and which dependencies require a shared boundary. Move owned, high-frequency actions behind direct application tools first.

Keep remote or cross-team capabilities on MCP until ownership changes. Run both paths against the same fixtures, error classes, authorization states, and production traces before removing an integration.

Sources

• Executable Code Actions Elicit Better LLM Agents (ICML 2024)
• Code execution with MCP: Building more efficient agents (November 4, 2025)
• Scaling MCP adoption (April 14, 2026; modified July 15, 2026)
• Model Context Protocol at First Glance (April 13, 2026)

By Blazity Team