The AI agent infrastructure wave is building. But agents need to do things, not just talk. MCP (Model Context Protocol) is emerging as a standard for how agents discover and invoke tools. The question for crypto: how does MCP adapt for onchain interactions, where the stakes are higher and the trust model is different?
Summary
MCP provides a standardized protocol for AI agents to discover tools, understand their schemas, and invoke them. For onchain agents, this means standardized interfaces to protocols—swap on Uniswap, deposit to Aave, vote on proposals. The core challenge: traditional MCP assumes trusted tool providers, but onchain interactions are adversarial. The opportunity is building MCP servers that bridge AI agents to DeFi safely.
What is MCP for Onchain?
MCP defines how an agent discovers what tools are available and how to call them:
MCP Core Concepts:
Tool Discovery:
Agent: "What tools do you have?"
Server: [
{ name: "swap", description: "...", schema: {...} },
{ name: "stake", description: "...", schema: {...} }
]
Tool Invocation:
Agent: { tool: "swap", args: { token_in: "ETH", token_out: "USDC", amount: "1.0" } }
Server: { result: "Transaction submitted", tx_hash: "0x..." }
For Onchain (what I'd build):
┌─────────────────────────────────────────────────┐
│ AI Agent │
│ "I want to swap 1 ETH for USDC on best route" │
└─────────────────────────────────────────────────┘
↓ MCP
┌─────────────────────────────────────────────────┐
│ Onchain MCP Server │
│ - Exposes DeFi protocols as tools │
│ - Simulates transactions before execution │
│ - Enforces safety constraints │
│ - Signs and submits transactions │
└─────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────┐
│ Blockchain (Ethereum, etc.) │
└─────────────────────────────────────────────────┘
The MCP server becomes the trust boundary—it mediates between the agent's intent and actual onchain execution.
The Trust Boundary Problem
Here's the key difference between offchain and onchain MCP: consequences are irreversible.
Traditional MCP (offchain tools):
Worst case: API call fails
Recovery: Retry or handle error
Stakes: Usually low
Onchain MCP:
Worst case: Funds drained
Recovery: None (transactions are final)
Stakes: User's entire wallet
Trust Model Shift:
Offchain: "Did the tool do what it said?"
Onchain: "Did the tool do ONLY what it said?"
"Could the tool have done something malicious?"
"Is the tool's contract verified and audited?"
An onchain MCP server that exposes a malicious swap tool could drain user wallets. The agent can't tell the difference between a legitimate tool and a malicious one without additional verification.
Impact
Agent composability improves. Standardized MCP interfaces mean agents can work with any protocol that exposes MCP tools. No custom integration per protocol.
But the security burden is significant. Every MCP tool is potential attack surface. Agents invoking tools need to verify tool behavior, not just trust tool descriptions.
Protocol discoverability changes. Protocols that expose well-designed MCP interfaces become more accessible to agents. It's a new distribution channel.
The MCP server is a chokepoint. Whoever runs the MCP server—translating agent intents to transactions—has significant power. They see all agent activity and can front-run, censor, or manipulate.
Failure Modes
Malicious Tool Injection: An attacker publishes MCP tools that look legitimate but execute malicious contracts. Agent invokes them, wallet drained.
Transaction Simulation Mismatch: MCP server simulates a transaction showing one outcome, but actual execution produces different results (state changed between simulation and execution).
Tool Description Manipulation: An agent decides what tools to use based on descriptions. A subtly misleading description could cause the agent to use a tool inappropriately.
MCP Server Compromise: If the MCP server is compromised, all agents using it are compromised. Centralized server = centralized risk.
What I'd Build
Tool verification layer. Every MCP tool that interacts onchain should link to verified contracts with audit reports. Agents should be able to verify that the tool's contract matches its description.
Tool with Verification:
{
"name": "uniswap_v3_swap",
"description": "Swap tokens on Uniswap V3",
"contract": "0x...",
"chain_id": 1,
"verification": {
"etherscan_verified": true,
"audit_urls": ["https://..."],
"known_protocol": "uniswap",
"risk_score": "low"
}
}Simulation-first execution. Every tool invocation simulates first. Agent sees exactly what will happen before authorizing execution. Mismatch between simulation and description = abort.
Spending limits in the MCP layer. The MCP server enforces spending limits independent of the agent. "This agent can spend max 0.1 ETH per hour" prevents runaway agent behavior.
Decentralized tool registries. Don't let one entity control tool discovery. Build registries where tool quality is socially verified, similar to npm but for onchain agent tools.
Lessons
-
MCP is the right abstraction level. Tools with schemas, discoverable interfaces, standardized invocation—this is how agents should interact with the world.
-
Onchain MCP needs additional trust layers. The standard MCP assumption (trust the server) doesn't work when mistakes are irreversible. Verification, simulation, and limits are essential.
-
Protocol interfaces are distribution. Protocols that expose great MCP tools get agent traffic. It's a new competitive dimension.
-
The MCP server is infrastructure. Running reliable, secure MCP servers for onchain agents is a business. Expect this to become an infrastructure category.
-
Agent safety is a stack problem. Safe onchain agents need safe tools, safe servers, safe execution, and safe wallets. MCP is one layer; it doesn't solve safety alone.
If you're building AI agents that interact onchain, start with the MCP pattern. The abstraction is right. But build or use MCP servers that take onchain safety seriously—simulation, verification, and spending limits are non-negotiable.