// AI AGENTS THAT TRADE

What is an MCP server? A trader's explanation

2026-07-16 · Mithril

If you trade programmatically, you've probably seen "MCP" appear in every AI product announcement since late 2024 and wondered whether it's something you need to care about. Short answer: yes, if you want an AI model to touch your trading stack. MCP — the Model Context Protocol — is the open standard that lets models like Claude call external tools, and it has become the default way to wire an LLM to an exchange, a database, or anything else with an API. This post is the trader's-eye explanation: what it is, how the pieces map to concepts you already know, and how to think about hosted vs local servers.

The problem MCP solves

A language model, out of the box, can only emit text. To make it do anything — fetch an order book, place an order — you historically had two options:

1. Write glue code yourself. Run an agent loop: the model outputs "I want to check the FED market", your code parses that, calls the Kalshi API, pastes the result back into the prompt. Fragile, bespoke, and rebuilt from scratch for every model and every API.
2. Build a vendor plugin. ChatGPT plugins (2023) were the famous attempt: an OpenAI-specific manifest format that worked in exactly one product. When the product pivoted, the ecosystem died with it.

MCP, introduced by Anthropic in November 2024 and since adopted well beyond Claude, replaces both with a neutral protocol. Think of it the way FIX works in traditional markets: instead of every buy-side firm writing custom connectivity to every broker, everyone speaks one wire protocol and any client can talk to any counterparty. MCP is FIX for model-to-tool connectivity — a standard handshake in which a server advertises what it can do and a client (the model's host application) calls it.

The vocabulary: tools, resources, prompts

An MCP server exposes up to three kinds of things. For trading, the first is what matters:

• Tools are functions the model can call, each with a name, a description, and a typed JSON schema for its arguments — e.g. place_order(market_id, side, price, size). The model reads the schema, decides when to call the tool, and gets structured results back. A tool is an action: it can change the world, so tool design is where all the safety questions live.
• Resources are read-only data the client can pull into the model's context — think reference material: a list of tradable markets, your fee schedule, venue documentation. Resources inform; they never execute.
• Prompts are reusable prompt templates the server offers ("analyze this market's order book"). Convenient, rarely load-bearing.

The critical design insight for traders: the tool list is a permission boundary. A model connected to a server that exposes search_markets and get_portfolio but not place_order is structurally incapable of trading, no matter what it's prompted to do. You don't have to trust the model's judgment; you constrain its reach. This is the same reasoning behind server-side risk limits — controls outside the model beat instructions inside it, every time.

What a trading MCP server looks like

A minimal prediction-market server exposes something like:

When you ask Claude "what's the Fed cut market trading at?", the model calls search_markets, receives JSON with prices and IDs, and answers from that data instead of guessing. When you say "buy 100 at 39 or better", it calls place_order with structured arguments — and the server decides whether that order is acceptable, checks it against limits, signs it with keys the model never sees, and returns the result. A concrete walkthrough of exactly this flow is in Trading Kalshi and Polymarket with Claude via MCP.

Why this beat bespoke plugins

Three properties, none of which the plugin era had:

• Write once, run everywhere. One MCP server works with Claude, Claude Code, and the growing set of other MCP-capable clients (including OpenAI's tooling, which adopted MCP in 2025). You are not betting your integration on one vendor's product roadmap.
• Typed contracts. Tools declare JSON schemas, so a place_order call arrives as validated structure, not as free text your glue code regex-parses. For anything touching money, that difference is not cosmetic.
• Composability. A client can connect several servers at once — market data from one, execution from another, your research notes from a third — and the model orchestrates across them. That's an agent architecture, not a chatbot feature.

Hosted vs local servers

MCP servers come in two deployment flavors, and for trading the choice has real security consequences.

Local servers run on your machine and are ideal when the tools touch local things: your files, your database, your backtest results. A local server for trading, though, means venue credentials sit on your laptop, in reach of the same process the model drives — every prompt injection becomes a potential key-theft attempt, and there's no independent layer enforcing limits. See why your agent should never hold your keys.

Hosted (remote) servers run as a service you connect to over HTTP with proper authorization (the spec uses OAuth-style flows). For execution this is usually the right shape, because the server can be more than a passthrough:

• credentials stay encrypted server-side, never on the agent's machine;
• risk limits are enforced in the server, outside the model's reach;
• every order is logged independently of the model's narration;
• you get one connection for multiple venues instead of one server per exchange.

A sensible split, common in practice: local servers for research and data wrangling, one hosted server as the sole path to the market.

What to do with this

If you just want to see it working, connect a Claude client to a trading server and place a sandbox order — the MCP trading tutorial takes about ten minutes, using Mithril's hosted server (mcp.trymithril.com/mcp) over Kalshi and Polymarket. If you'd rather write code than chat, the same concepts apply when an AI coding agent builds against a REST API directly — that path is covered in the Claude Code bot walkthrough. And for the full safety architecture that should sit behind any trading tool you hand to a model, start at the hub: How to let an AI agent trade prediction markets safely.

The MCP spec and client support evolve quickly. Details above reflect the state of the ecosystem as of July 2026 — check the current spec at modelcontextprotocol.io before building.