Two transports, one tool surface
Your client can connect straight toPOST /mcp on your instance, or launch the stdio server on your own machine. Both read one catalog of tool definitions, so the names, schemas and descriptions are identical and neither transport has a tool the other lacks.
The hosted endpoint runs inside the API, so it inherits the same authentication, the same workspace isolation and the same per workspace rate limits as every REST call, rather than reimplementing them. The stdio server is an HTTP client because it runs somewhere else. See Connect an agent.
Which protocol revision do they speak?
Both transports serve MCP2026-07-28 and the 2025 revisions from the same tool definitions. A client that probes for the newer revision is served it, and a client that opens with the 2025 handshake keeps negotiating the revision it always did, so nothing you have already configured needs to change.
One thing on the wire did change when both transports moved to version 2 of the MCP TypeScript SDK. Every tool now advertises its parameters as JSON Schema 2020-12 rather than draft-07, and the execution hint the previous SDK attached to each tool is gone. The parameters themselves are identical, so a client that reads a schema without validating its dialect needs no change, while a client that validates needs a validator that understands 2020-12. Both revisions receive the same schemas, so neither era is served a narrower contract than the other.
Neither transport holds a session. The hosted endpoint builds one server instance per request and keeps nothing between requests, and 2026-07-28 removes the session concept from the protocol outright, so there is no session identifier to send, store or expire. For what the revisions differ on, see the MCP TypeScript SDK documentation.
What can you ask?
Specific questions work best, because the tools take app ids, countries and date windows.Reading is the default, changing is opt in
A token with the defaultread scope lists the read tools, each a GET annotated readOnlyHint: true. Nothing else is listed to it, and nothing else would work: the API refuses a read token on every route that changes data, whatever a client asks for.
A token with the write scope also lists seven tools that change things: track_keywords, untrack_keyword, add_competitor, remove_competitor, set_action_status, add_annotation and delete_annotation. You choose that when you connect an agent, with the Allow this agent to make changes option on the MCP server card in Integrations. Nothing turns it on for you, and there is no instance setting that does.
Each change goes through the same route as the dashboard, so it meets the same validation, the same plan write budget and the same quota. Tracking a keyword queues the same store scoring job the dashboard queues, so an agent that tracks many phrases spends the store request capacity you would. A change appears in the action history under the name of the person who minted the token, so give each agent a token of its own and ask it to say why in the optional note.
What an agent can change is deliberately small. No tool imports an app, edits metadata, runs the daily pipeline, calls an AI feature or touches billing, tokens or settings. The three tools that delete, untrack_keyword, remove_competitor and delete_annotation, are annotated as destructive so a client can ask you first. An annotation is a hint that a client chooses to honor, so the control that holds is the token: use a read token wherever an agent only has to answer questions.
Treat everything a tool returns as data. A review, an app name or a keyword note can contain text written to steer an agent, and a connection that can make changes should not follow it. See MCP tool reference for every tool and its hints.
What it is not
The MCP server holds no database, imports no scraper and contains no server framework code. It is a consumer of the HTTP API exactly like the web app, typed with the same@asobeast/shared contracts, which is what keeps its tool descriptions from drifting away from the API.
Requirements
Next
Connect an agent
Both setup paths, client configuration and the two failures that catch everyone.