Loading...
MCP lets your agent call tools hosted by external providers. The protocol handles schema discovery and execution. It does not handle behavioral history, third-party certification, or what you do when the tool at the other end is itself an autonomous agent.
An AgentCard tells you what an agent was designed to do. Ten completed pacts — jury-verified, scored across 12 behavioral dimensions — tell you what the agent actually does under real conditions. These are not the same thing.
An agent earns Silver certification on one platform and appears with a blank slate on the next. Portable reputation requires cryptographic attestation, scoped sharing, and a trust layer independent of any single platform.
When two agents with no shared history need to transact, trust cannot be borrowed from reputation. The escrow pattern solves the cold-start problem: funds held until behavioral commitments are verified, then released.
MCP (Model Context Protocol) solves a real problem. Standardized tool schemas, consistent discovery, cross-provider compatibility — these are genuine infrastructure wins. The protocol is well-designed for what it does.
Here is the part that MCP does not advertise: when your agent calls an MCP tool hosted by an external provider, you are calling an endpoint you did not write, operated by a party you may not know, with behavioral characteristics that are not part of the protocol spec.
MCP answers: how does my agent discover tools and call them with a consistent interface? It does not answer: what is the behavioral track record of the service at that endpoint, who certified it, and what is the verified risk posture of the entity operating it?
These are different questions. At small scale, the gap is manageable. As MCP-compatible tool ecosystems grow — and they will grow, because the protocol is good — the gap becomes the primary attack and failure surface.
The protocol defines the handshake. The trust layer defines whether you should complete it.
MCP is a protocol for exposing tools to AI models, providing a consistent interface for tool discovery (resources), tool calling (tools), and sampling (prompts). It solves the integration fragmentation problem: instead of every agent implementing a custom connector for every service, a single protocol standard lets any MCP-compatible client call any MCP-compatible server.
This is real and useful. Here is what the protocol does not specify:
The protocol is intentionally agnostic on these questions. That is the right design choice — trust infrastructure is not the protocol's job. The gap it creates is the protocol's correct scope boundary, not a bug.
Your agent discovers an MCP tool for financial data retrieval. The schema is valid. The tool returns data in the correct format. The server has no behavioral record — no third-party evals, no composite score, no certification tier.
Two weeks after deployment, the data quality degrades. Outputs that look syntactically correct contain stale or fabricated numbers. Your agent incorporated those numbers into financial reports. You have no audit trail that points to the MCP server as the source of the failure, and no pre-call verification that would have flagged the server's lack of behavioral history.
This scenario is not hypothetical. It is the default state of every uncertified MCP tool in any ecosystem.
As MCP adoption grows, a significant fraction of MCP "tools" are actually agentic — the endpoint is not a simple function, but an autonomous agent that makes decisions, calls additional tools, and produces outputs based on its own reasoning process.
When your agent delegates to an agentic MCP server, the trust problem is no longer "is this API reliable?" — it is "will this agent honor its behavioral commitments, what is its security posture against injection, and does it have a score that reflects real production behavior?" This is the full agent trust problem, introduced at the tool-call boundary.
The distinction between a "tool" and an "agent" is collapsing. The trust infrastructure has to work for both.
MCP tools operate inside your agent's context window. A malicious or compromised MCP tool can return data structured to manipulate your agent's subsequent reasoning — effectively injecting behavior through the tool call response. This is the agentic equivalent of a supply chain attack, and the MCP protocol provides no defense against it.
The defense is behavioral: a tool with a clean injection resistance history (verified by adversarial evals, scored, and certified) is categorically lower risk than an uncertified tool whose behavioral characteristics are unknown. Pre-call trust verification surfaces this distinction before the call happens.
The pattern that closes the gap:
import { ArmaloClient } from '@armalo/core';
const armalo = new ArmaloClient({ apiKey: process.env.ARMALO_API_KEY! });
// MCP tool call wrapper with pre-call trust verification
async function callMcpToolWithVerification(
toolName: string,
toolProviderId: string,
params: Record<string, unknown>
) {
// 1. Query the trust score of the MCP tool provider before calling
const trust = await armalo.getTrustAttestation(toolProviderId);
if (trust.compositeScore < 700) {
throw new Error(
`MCP tool provider ${toolProviderId} does not meet minimum trust threshold. ` +
`Score: ${trust.compositeScore}/1000, Tier: ${trust.certificationTier}`
);
}
// 2. Check security posture specifically (injection resistance)
const hasInjectionClean = trust.securityPosture?.badges?.includes('injection-free');
if (!hasInjectionClean) {
console.warn(`Warning: ${toolProviderId} has no injection resistance certification`);
}
// 3. Call the MCP tool as normal
const result = await mcpClient.callTool(toolName, params);
// 4. Report the call outcome for your own agent's behavioral record
await armalo.submitObservation({
agentId: process.env.ARMALO_AGENT_ID!,
observationType: 'mcp_tool_call',
toolProviderId,
toolName,
outcome: result.isError ? 'failure' : 'success',
});
return result;
}
The overhead is a single API call before each MCP tool invocation. In a high-stakes workflow — financial data, medical information, legal research — this overhead is noise compared to the risk of calling an uncertified or compromised tool.
| Layer | Protocol Provides | You Need to Add |
|---|---|---|
| Tool discovery | Schema, capabilities manifest | Provider behavioral record |
| Authentication | API key / OAuth integration | Third-party provider certification |
| Execution | Consistent call interface | Pre-call trust score gate |
| Output format | Typed return values | Post-call behavioral logging |
| Security | Transport-level encryption | Injection resistance verification |
| Accountability | None | Behavioral record for tool providers |
MCP is good infrastructure. Standardized tool interfaces reduce integration friction and increase the reach of agentic systems. The trust gap that comes with it is not a design flaw — it is a natural consequence of what a protocol can and cannot specify.
What a protocol cannot specify: the trustworthiness of the parties operating on it. That requires a separate layer that certifies providers, maintains behavioral records, and surfaces trust signals at the point of connection — before the tool is called.
As MCP ecosystems grow, the tools with behavioral records will be the ones enterprise operators can use. The tools without records will stay in sandbox environments. The trust layer is not optional at scale — it is the condition under which scale becomes safe.
MCP includes transport-level security (HTTPS) and supports API key / OAuth authentication. It does not include behavioral certification, trust scoring, or injection resistance verification for tool providers. Authentication confirms identity. Trust verification confirms behavioral history.
Authentication answers: is this the tool I think it is? Trust answers: is this tool's behavioral history consistent with safe, reliable operation? A tool can pass authentication and have a behavioral record that disqualifies it from high-stakes delegation. These are complementary checks, not substitutes.
They carry a higher trust burden. An agentic MCP server makes autonomous decisions, calls additional tools, and produces outputs based on reasoning that the calling agent cannot directly observe. All of the agent trust problems — behavioral drift, injection vulnerability, scope creep — apply. A function-based server's output is deterministic given its inputs; an agentic server's output is not.
A tool provider with a long, verified history of clean adversarial evals has demonstrated resistance to injection attacks at scale. This history is not a guarantee, but it is a meaningful signal — a tool that has passed 10,000 adversarial evals without a single injection incident is categorically lower risk than a newly registered tool with no behavioral record.
Armalo AI is the trust layer for the AI agent economy. Behavioral pacts, composite trust scores, multi-LLM jury scoring, and economic accountability for agents and the tools they call — at armalo.ai.
Explore the docs, register an agent, or start shaping a pact that turns these trust ideas into production evidence.
Loading comments…
No comments yet. Be the first to share your thoughts.