What Is Model Context Protocol (MCP)?

What Is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is an open JSON-RPC protocol for connecting LLM agents to external tools, data sources, and context providers. An MCP server advertises tools, resources, and prompts; an MCP client inside the agent host discovers and calls them through one portable interface. In FutureAGI traces, MCP calls appear as tool spans that can be evaluated for tool selection, argument correctness, latency, and policy failures.

Why MCP matters in production LLM and agent systems

Before MCP, every LLM platform used its own plugin or function-calling format: OpenAI plugins, Anthropic tool-use, custom JSON schemas in LangChain, and vendor-specific SDKs. Teams duplicated every tool integration for each host. Unlike OpenAI function calling, which describes how one model API asks for a tool, MCP defines a host-to-server protocol that can be shared across clients. That difference matters when an agent stack must change models without rewriting every database, browser, ticketing, or warehouse connector.

The pain shows up in three roles. Platform engineers maintaining a database wrapper otherwise reimplement it for OpenAI, Anthropic, and the in-house framework, with three integrations going stale at different rates. Security teams cannot enforce a single audit pattern when each integration emits different log formats. Compliance leads cannot prove that every tool call routes through the same governance layer when each tool speaks a different dialect.

For 2026 agent systems, the importance compounds. Multi-agent stacks where agents call other agents need a common protocol; A2A protocol layered on MCP gives that. Long-running agents that call ten tools per task need consistent observability; MCP plus traceAI gives one span shape across them. Enterprise rollouts that govern data access need a single policy enforcement point; an MCP gateway in front of every server gives that.

The risk is also real. An MCP server with broad tool exposure becomes an excessive-agency vector — an indirect prompt injection embedded in a tool response can trigger lateral tool calls. Every MCP integration needs a guardrail layer between the LLM and the server, not just at the model boundary.

How FutureAGI evaluates MCP-connected agents

FutureAGI uses the mcp traceAI integration to instrument MCP clients in Python and TypeScript. After instrumentation, every tool call, resource read, and prompt fetch becomes a span with agent.tool.name, mcp.server.name, and mcp.tool.input/mcp.tool.output attributes. The span tree shows the full trajectory: LLM step → MCP tool call → tool response → next LLM step.

On top of those traces, FutureAGI runs evaluators. FunctionCallAccuracy scores whether the agent picked the right tool with the right arguments; ToolSelectionAccuracy scores tool-selection at each decision point; TaskCompletion scores whether the multi-tool trajectory reached the goal. In the dashboard, eval-fail-rate sliced by mcp.server.name identifies the failing integration instead of only reporting a single end-to-end pass-fail.

For governance, the FutureAGI Agent Command Center sits in front of MCP servers as a policy enforcement layer. pre-guardrail blocks tool calls that violate policy, such as an MCP database tool the user lacks access to. post-guardrail scrubs PII from tool responses before the LLM sees them, and traffic-mirroring shadows MCP traffic to a sandbox for offline eval. FutureAGI’s approach is to treat MCP as a protocol boundary: trace it, evaluate each call, then enforce policy before the next agent step.

How to measure MCP in production

Concrete signals when running MCP-connected agents:

• agent.tool.name — OTel span attribute identifying which MCP tool was invoked; slice eval failures by this to find faulty tools.
• FunctionCallAccuracy — returns whether the right tool was called with the right arguments; the headline metric for MCP agents.
• ToolSelectionAccuracy — scores tool selection at each decision point in the trajectory.
• MCP server latency p99 — span duration under the MCP tool span; surfaces upstream-tool slowness as an agent regression cause.
• Tool-call count per task — agent.trajectory.step count filtered to MCP tool spans; detects loops and inefficient trajectories.

Minimal Python:

from fi.evals import FunctionCallAccuracy, ToolSelectionAccuracy

fca = FunctionCallAccuracy()
tsa = ToolSelectionAccuracy()

# Score a captured trajectory:
# fca.evaluate(input=..., output=tool_call, expected_output=expected_call)

Common mistakes

• Trusting an MCP server’s advertised tool list as static. Servers can add or remove tools at runtime; refresh discovery and alert on unexpected schema changes.
• Skipping the guardrail between LLM and MCP server. Indirect prompt injection in a tool response can trigger lateral calls before normal output filters run.
• Evaluating only end-to-end task completion. A task-level pass hides wrong intermediate tools; slice failures by mcp.server.name and agent.tool.name.
• Sharing MCP credentials across users. Each MCP session needs its own authorization scope; otherwise one agent run can inherit another user’s tool access.
• Ignoring argument-schema drift. A changed input field can create silent no-op calls; pin schema versions and run FunctionCallAccuracy on recorded trajectories.