💡 TL;DR — Don't merge the MCPs into one mega-server, and don't build them subgraph-shaped. Run them as a federation that rides Horizon: a discovery layer over any Graph data service, an access rail that's a thin adapter on Horizon's unified payments (x402 gateway · GraphTally · gateway API keys, settled in GRT), and any number of specialized domain MCPs and agents that plug in permissionlessly. This is the consumer-side implementation of The Graph's own 2026 thesis: the data layer for the agentic economy.
Horizon (live since Dec 2025) turned The Graph from a subgraph-only network into a multi-service data protocol. Three protocol innovations matter here:
The 2026 roadmap makes the agentic intent explicit: a Q2 2026 x402-compliant gateway with MCP and A2A support, GraphTally trust-minimized payments, and Subgraph MCP/A2A integrations targeting Claude, Cursor, and ChatGPT — so agents query and pay per-call with no setup keys.
The takeaway for this design: don't reinvent any of that — ride it. The federation is the agent-facing surface on top of Horizon's economics, not a parallel stack.
Three different jobs hide in this stack, each with a different change rate, owner, and trust boundary:
Collapsing them into one server causes tool overload (agents face a flat list of dozens of tools and choose worse), coupling (a Tycho change shouldn't break an AAVE MCP), and versioning gridlock (everything ships at the slowest component's pace).
The opposite extreme — siloed MCPs with no shared discovery — is just as bad: every agent has to hard-code knowledge of each server. The discovery layer exists precisely to prevent that.
Two shared horizontal layers, plus N vertical domain MCPs / agents on top — all sourcing from Horizon data services.