MCP endpoint vs embedded agent: what an exchange gives up

AI is arriving at exchanges by two roads. One is to publish an MCP server, so traders can connect the AI assistant they already use to their exchange account. The other is to embed a conversational trading agent inside the exchange’s own app. Both get described as “AI-ready”. They are very different products with very different consequences for the venue.

What each option is

An MCP endpoint. The Model Context Protocol is an open standard for connecting AI applications to tools and data. An exchange that publishes an MCP server exposes a set of functions, for example fetching prices, reading balances or submitting orders, that an external AI assistant can call on the trader’s behalf. Several exchanges and brokers have published one.

An embedded agent. A conversational agent built into the exchange’s app, using the exchange’s data and order API, under the exchange’s brand and account system. For the full definition, see what an embedded conversational trading agent is.

Side by side

	MCP endpoint	Embedded agent
Where the conversation happens	In a third-party AI app	In the exchange’s own app
Who the trader sees	The AI provider’s brand	The exchange, with the agent inside it
Who reaches the trader	Traders who already use external AI tools and can set up a connection	Every trader who opens the app
Confirmation experience	Set by the external app; varies	Designed by the exchange and the agent vendor; consistent
Advice boundary	Depends on the external model and its settings	Tested behaviour the exchange can verify
Engineering effort	Lower: publish and maintain an endpoint	Integration of an SDK panel and API connection
Data the exchange learns	Function calls only	What traders ask, where they get stuck, what they try
Effect on attention	Pulls the session out of the exchange	Keeps research and action on the venue

What the exchange gives up with MCP alone

The surface. The richest part of the interaction, the question and the answer, happens in someone else’s product. The exchange becomes a back end.

The confirmation design. How an order is presented and confirmed is decided by the external app. Some do it well. The exchange cannot ensure that every AI-originated order on its venue was shown and confirmed in a consistent way. We explain why that matters in why confirm-by-default matters for AI order flow.

The advice boundary. A general-purpose assistant may comment on what to buy, predict prices, or speculate, around a perfectly well-behaved endpoint. The exchange’s account is involved in the result; the exchange’s controls are not. For what a tested boundary looks like, read how an AI trading agent avoids giving investment advice.

The learning. The questions traders ask are some of the most valuable product signal an exchange can get. Over MCP, the exchange sees function calls, not the conversation that produced them.

When MCP is the right call

An MCP server is a reasonable thing to ship, and often worth shipping, when:

• A meaningful share of the exchange’s traders already work inside external AI tools.
• The endpoint is scoped carefully, for example read-only by default, with order functions behind explicit permissions.
• It is treated as a developer and power-user channel, not as the exchange’s AI strategy.

The case for doing both

These options are not mutually exclusive. An MCP server serves the traders who live in external AI tools. An embedded agent serves everyone else, which for most venues is the large majority, and it does so on the exchange’s terms. The mistake is to ship the endpoint, tick the “AI” box, and leave the main app without a conversational layer.

Questions to decide internally

1. What share of our traders use external AI tools today, and for what?
2. Are we comfortable with AI-originated orders confirmed in interfaces we do not control?
3. Do we want the trader’s questions as product signal?
4. How fast can we put a conversational layer in our own app?

askthehippo.com covers how Hippo embeds in an exchange app.