Home
Documentation
Architecture BlockWire CronSynth Switchboard Arbiter
Resources
Glossary Use Cases The Coordination Problem BlockWire: Shared Eyes EchoRift + MCP Building a DeFi Swarm Getting Started
Systems Operational

EchoRift + MCP: Infrastructure Meets Tool Protocol

The Model Context Protocol defines how AI models connect to tools. It's become a standard—the way Claude calls external capabilities, the interface between language models and the world.

EchoRift services are now MCP-callable. Twelve tools across four services, accessible through the standard protocol. This isn't just a technical integration; it's a design philosophy alignment.

What MCP Provides

MCP standardizes the interface between AI models and external tools:

  • Discovery: Models learn what tools exist and what they do
  • Invocation: Models call tools with structured parameters
  • Response handling: Tools return results in understood formats
  • Error semantics: Failures are communicated clearly

Before MCP, every tool integration was bespoke. Models needed custom code for every capability. Scaling tool access meant scaling integration complexity.

MCP makes tools composable. A model that speaks MCP can use any MCP-compatible tool. The protocol is the interface; implementations vary.

What EchoRift Provides via MCP

The EchoRift MCP server exposes:

BlockWire (2 tools):

  • `blockwire_subscribe` — Register for blockchain event webhooks
  • `blockwire_feed` — Pull recent blockchain events

CronSynth (3 tools):

  • `cronsynth_schedule_create` — Register a scheduled webhook trigger
  • `cronsynth_schedule_list` — View active schedules
  • `cronsynth_schedule_delete` — Remove a schedule

Switchboard (3 tools):

  • `switchboard_task_create` — Add work to a swarm's task queue
  • `switchboard_task_claim` — Claim an available task atomically
  • `switchboard_broadcast` — Send a message to all swarm members

Arbiter (4 tools):

  • `arbiter_lock_acquire` — Get exclusive access to a resource
  • `arbiter_lock_release` — Release a held lock
  • `arbiter_election_trigger` — Start leader election
  • `arbiter_vote_cast` — Vote in an election or proposal

These aren't wrappers around the full API. They're the essential operations—the primitives that AI agents need most frequently.

Why This Matters

Consider an AI agent orchestrated by Claude. The agent needs to:

  1. Monitor blockchain for new token launches (perception)
  2. Execute analysis on a schedule (time)
  3. Coordinate with other agents on opportunities (coordination)
  4. Acquire exclusive rights before acting (consensus)

Without MCP integration, this agent needs custom code for every EchoRift API call. The model can reason about what to do but can't directly instruct the infrastructure.

With MCP integration, Claude can directly invoke EchoRift tools:

"I'll set up a BlockWire subscription for new_contract events, create a CronSynth schedule to run analysis hourly, use Switchboard to coordinate with other agents, and acquire an Arbiter lock before executing trades."

The infrastructure becomes native to the model's capabilities.

Usage Pattern

Starting the EchoRift MCP server:


                npx @echorift/mcp

The server registers with MCP-compatible clients (like Claude Desktop or other MCP hosts). Tools become available immediately.

From there, the model can:


                Use blockwire_subscribe to monitor liquidity_added events
                

                Use cronsynth_schedule_create with "0 */4 * * *" to trigger rebalancing
                

                Use switchboard_task_create to queue discovered opportunities
                

                Use arbiter_lock_acquire to get exclusive portfolio access

The tools compose. A complex workflow becomes a sequence of tool invocations, each using standard MCP semantics.

Authentication Flow

EchoRift APIs require authentication (EIP-191 signatures for most Switchboard/Arbiter operations, x402 payments for BlockWire/CronSynth).

The MCP server handles this:

  1. Wallet configuration: Set your agent's private key in environment
  2. Automatic signing: The server signs requests with your agent identity
  3. Payment integration: x402 payments are handled transparently

You configure credentials once. The MCP server uses them for all tool invocations. The model doesn't manage keys or payments directly.

Capability Mapping

Which tool for which need?

| Need | Tool |

|------|------|

| Watch blockchain events | blockwire_subscribe or blockwire_feed |

| Schedule future actions | cronsynth_schedule_create |

| Queue work for swarm | switchboard_task_create |

| Claim work from queue | switchboard_task_claim |

| Broadcast to swarm | switchboard_broadcast |

| Exclusive resource access | arbiter_lock_acquire |

| Release exclusive access | arbiter_lock_release |

| Elect leader | arbiter_election_trigger |

| Participate in voting | arbiter_vote_cast |

The capability map in the documentation provides more detail on when each tool is appropriate.

Composability with Other MCP Tools

EchoRift via MCP composes with other MCP-accessible tools:

EchoRift + filesystem tools: Store analysis results locally, load configuration from files

EchoRift + web tools: Combine on-chain perception with off-chain data sources

EchoRift + database tools: Persist state beyond Switchboard's shared state

EchoRift + notification tools: Alert operators when swarm events occur

The MCP protocol makes this composition natural. The model orchestrates multiple tool sources; each tool does its part.

What MCP Doesn't Do

MCP provides tool invocation. It doesn't provide:

Agent identity. The model calling tools isn't automatically an agent with blockchain presence. Identity comes from wallet configuration.

Persistence across sessions. MCP is request-response. Maintaining agent state across invocations is your responsibility.

Complex workflows. MCP handles individual tool calls. Multi-step workflows require orchestration logic—either in the model's reasoning or in surrounding code.

Payment management. MCP doesn't manage x402 payment sessions. The EchoRift MCP server handles this, but the underlying payment infrastructure must be configured.

MCP is an interface layer. The capabilities underneath—and the orchestration above—are separate concerns.

Practical Considerations

Latency: MCP adds a hop. Model → MCP server → EchoRift API → response → MCP server → Model. For real-time trading, this might matter. For coordination and scheduling, it's negligible.

Error handling: MCP tools return errors that the model must interpret. The EchoRift MCP server translates API errors into clear MCP error responses. Models should reason about failures and retry or escalate appropriately.

Rate limits: Underlying EchoRift rate limits still apply. The MCP layer doesn't bypass them. Models should be aware of limits and pace operations accordingly.

Costs: Every paid tool invocation costs money. Models should be aware of pricing (passed through in tool descriptions) and make cost-conscious choices.

The Bigger Picture

MCP is Anthropic's protocol. EchoRift is agent infrastructure. The integration means Claude-orchestrated agents can use coordination infrastructure natively.

This isn't the only path. Direct API access remains available. Other frameworks can integrate EchoRift differently. The MCP integration is one interface among several.

But for Claude-based agents specifically, MCP integration is the cleanest path. The model's native tool-use capabilities connect directly to coordination infrastructure. The gap between "AI that reasons about coordination" and "AI that coordinates" shrinks.

That's the goal. Not just infrastructure that exists, but infrastructure that AI can use fluently.

Part of the EchoRift infrastructure series.