The Protocol Surface Bet

Lessons from a year building MCP servers across five prediction market venues.

Every prediction market protocol is racing to build "their" AI agent. Every agent platform is racing to be "the" agent. Both bets are real. Both miss a third thing.

A prediction market venue has a choice when AI agents become serious consumers of its data. Option one: build a chatbot that lives inside the existing UI, owns the user experience end-to-end, and only knows how to talk about its own venue. Option two: expose the venue's primitives as a protocol, an MCP server, an OpenAPI spec, an SDK, and let any agent on the user's side compose those primitives alongside whatever else the user cares about.

Over the past year at IQ AI I've been close to five MCP servers shipping across the prediction markets stack: Polymarket, Kalshi, Opinion.trade, Limitless, and now Pear Protocol. I built Pear myself. I led Opinion.trade. Polymarket I worked on as the second engineer, behind our tech lead. Kalshi was built by the tech lead with another engineer. Limitless was built by our CTO and tech lead. I followed both closely. Each of those five taught me a different thing about what changes when the consumer of your API is not a human clicking buttons, but an agent calling tools on someone else's behalf.

This is the case for why both options should exist, and why the second one is harder to get right than it looks.

About two weeks into shipping mcp-pear, I DM'd a friend on the Pear team with a short video of me interacting with Pear Services through Claude Desktop. The response came back friendly. The pushback was sharp.

His first read: "this is reinventing the wheel, we already have Agent Pear integrated into the system." Then a few minutes later: "why can't they just use Agent Pear? It gives pair trade ideas and alpha with a stats server attached to it, obviously better than Claude." I had no counter for the alpha bit. He was right. Agent Pear has access to Pear's internal stats server. Claude doesn't. mcp-pear is not going to win on signal quality against a first-party agent that owns the venue's full data stack.

So I told him what I actually thought.

Agent Pear lives inside Pear. It follows Pear's UX. It can only reach Pear. mcp-pear lets any agent speak to Pear natively, alongside whatever else that agent already speaks. Picture a trader who uses Claude Desktop for email, research, calendar, document review, and now wants to ask "what's the BTC/ETH ratio right now" in the same window without context-switching. Picture a developer assembling a flow that aggregates signals across Polymarket, Limitless, and Pear into one dashboard. Neither of those people will open Agent Pear. Not because Agent Pear is bad. Because their workflow is already centered somewhere else.

That distinction matters. Destination agents and protocol surfaces are different products solving different problems. The mistake is treating them as substitutes when they're complements.

There was a harder version of the same conversation a day later, and the composition argument did not fully answer it. The traders Pear actually serves are not developers. They run their lives in chart software, not in Claude Desktop. They are not the kind of people who set up an agent-driven workflow to manage their cross-venue trades. They are working professionals using interfaces optimized for them, and asking them to adopt a new toolset is not a small ask.

This is real. It is not a critique I can wave away with composition.

Here is my honest read. mcp-pear is not for the trader who is already on Pear. It is for the developer two steps removed: the person building a Discord bot for a sentiment-trading community, the person assembling a portfolio dashboard that needs prediction market data alongside spot prices and on-chain positions, the person stitching together a research workflow that touches six different venues. Those developers are downstream of Pear's current users in one sense, and upstream of Pear's future users in another. They serve audiences that do not currently know Pear exists. Each MCP server I publish is a small bet that those audiences are worth reaching, even if the reach is indirect.

The venue does not need everyone to come to its UI. It needs every interface someone builds to be able to speak its language.

 

Kalshi, built by our tech lead with another engineer, was the regulated one. Authentication is RSA-PS256: you generate a key pair, upload the public key to your account settings, and sign every request with the private key. There is no API-key shortcut. KYC and identity verification have to clear before anything works. Paper trading is not exposed through the API at all, only live funded accounts. Each of those constraints maps directly to a regulatory requirement that does not exist at Polymarket or Limitless. The lesson is one I underestimated going in: regulation shapes the API surface as much as the underlying protocol does. The MCP server has to expose enough of the auth flow that a developer building on top can stay within the regulator's lines, without surfacing complexity their users do not need to see.

Opinion.trade, the first MCP server I led, was the smallest tool surface of the five. API-key auth, no wallet ceremony, no transaction signing. The exposed tools are read-heavy: market discovery, price history, orderbook, position retrieval. No trade execution in this build. I went back and forth on whether that was a limitation worth fixing or a feature I should leave alone. I left it alone. Not every venue benefits from exposing full trade execution through MCP, especially when the agent integrations most likely to land first are analytical rather than transactional. Pure analytics composition is a real category. The lesson: the temptation to expose everything an API can do is real, and resisting it sometimes produces the more useful tool.

Limitless, built mostly by our CTO and tech lead, was the most thoughtfully designed of the five for developer experience. The MCP server has an explicit split between public endpoints, which require no environment variables at all, and authenticated endpoints, which use an EIP-712 signing flow. You can boot up the server and start querying active markets, positions, and orderbooks before you have a wallet configured. That distinction maps onto a real product behavior: prediction markets are inherently spectator-friendly. People want to look before they trade, and analytics agents have entirely different needs than execution agents. The lesson: design for the analyst-agent separately from the trader-agent, and let each one consume only what it actually needs.

Pear was the most recent and the most distinctive of the five. It's also the one I'm closest to, since I shipped it myself this month. The venue trades pair markets, long one composition, short another, and the data primitives reflect that. Markets are identified by composition keys like L:BTC|S:ETH, not single-asset symbols. There is no dedicated pair-ratio endpoint; the server synthesizes one by searching the markets index. The auth flow supports three modes. One of them, a JWT pass-through path, lets external orchestrators mint tokens themselves and inject them via env. The MCP server treats the token as opaque. The lesson: when a venue has unique primitives, the MCP server's job is to expose them in agent-native form. Mirroring the human UI works against you. Translating the underlying mechanics works for you.

What "infrastructure for builders" actually means depends on whose builders you are talking about.

The trader on Polymarket does not want a fifth tab open. They want their existing trading workflow, with maybe one or two new agent-driven helpers layered on top. The portfolio operator building a custom dashboard for a private Discord community does. The independent developer who wants to combine event-contract pricing from Kalshi, decentralized order flow from Polymarket and Limitless, and pair compositions from Pear into one signal feed wants it desperately. The agentic-tooling team at a fund who is testing whether LLMs can reason about cross-venue arbitrage during market open wants it more than anyone.

Each of those audiences is small today. None of them is the venue's current power user. All of them are people who, when the tool exists, will start producing interfaces that bring new people to the venue from directions the venue would never have reached on its own. A Discord bot built by a trader in a private group brings their community in. A portfolio dashboard built by a developer for their friends brings the friends in. An agent run by a fund's quant team brings institutional flow.

This is not a "we'll build it and they will come" argument. It is a more modest claim. If the protocol surface exists, the people who build interfaces on top of it can choose to include this venue in their work. If the surface does not exist, those interfaces have to integrate venue-by-venue, often skipping the smaller players entirely. The bet is that protocol-level composability is the cheapest way for a venue to remain reachable by every interface that gets built, including the ones nobody can predict yet.

There are at least three ways this thesis could turn out to be premature.

The first is that agentic tooling matures more slowly than the bull case requires. Three years from now we might look at MCP the same way we look at WSDL or RSS, a useful idea that never quite reached the audience it deserved. The second is that the builder audience never crosses the chasm. Maybe the audience for cross-venue prediction-data composition really is just a few hundred developers worldwide, and protocol-level integration only matters for venues large enough to draw their attention. The third is that first-party agents do win the end-state, and what feels like a category divide today collapses into the destination-agent model entirely.

I do not think any of these are likely. I have been wrong before. The hedge against being wrong is that the cost of being wrong is small. An MCP server is a few hundred lines of code that maps cleanly onto an existing API. The downside if the bet does not land is one weekend of work per venue. The upside if it lands is that an interface I never imagined turns out to depend on the server I shipped six months ago.

After watching five of these ship across the stack, the thesis still holds. A venue does not need everyone to come to its UI. A venue needs every interface someone builds to be able to speak its language. Destination agents are a fine answer to one question. Protocol surfaces are the answer to a different question that has not been asked yet at scale.

I will know in two years whether the bet was early or wrong. In the meantime there are more venues to wrap, more downstream developers to reach, and more conversations like the one on Discord that taught me what I actually think.