What is MCP, explained for teams running several agents
MCP is the JSON-RPC protocol an agent uses to list and call tools on a server. For teams, one remote server means shared connections, one policy and one ledger.
The Model Context Protocol (MCP) is an open protocol that lets an AI agent discover and call tools on a server over JSON-RPC. A client sends tools/list to learn what it may call and tools/call to run one. For a team running several agents, the question that matters is what changes when every agent talks to the same remote server.
- Agent (the client) → MCP server initialize
- MCP server → Agent (the client) capabilities and instructions
- Agent (the client) → MCP server tools/list
- MCP server → Agent (the client) names, descriptions, input schemas
- Agent (the client) → MCP server tools/call name, arguments
- MCP server → Agent (the client) result, or isError: true
How does MCP work on the wire?
An MCP client, the agent, connects to an MCP server, which holds tools. The two speak JSON-RPC. The client calls initialize, then tools/list for the tool names, descriptions and input schemas, then tools/call with a name and arguments. The server returns a result, or a result with isError: true when the tool refused or failed.
Local servers run as a process next to the client and talk over stdio. Remote servers answer over HTTP using Streamable HTTP. CoreSpeed's server is remote, at https://api.corespeed.io/mcp. Its transport is stateless: one JSON-RPC call per HTTP request, batches rejected, no GET /mcp stream. Each request stands on its own, which is what lets any client reconnect at any time.
Tool names on CoreSpeed follow one pattern, capability__operation: memory__search_memory, web__search, media__generate, social__x_search, and notion__create_page or slack__post_message for connected apps. A remote server your org registers appears as org__slug__tool.
How does authorization work?
The MCP specification uses OAuth. A client that reaches a protected server discovers the authorization server through protected-resource metadata (RFC 9728), registers itself dynamically (RFC 7591) when it has no client id, and signs the user in with OAuth 2.1 and PKCE. The token it receives is audience-bound to /mcp (RFC 8707) and works only on POST /mcp.
For a person at a client, that is one browser sign-in. For a headless job, it is an API key in an Authorization: Bearer header. CoreSpeed has four credential forms over two principal kinds: browser sign-in and the sk-cs- member key act as you; the sk-csa- agent key is an agent principal with an identity of its own; a session JWT is what the cs CLI and the dashboard hold. The authentication page has the details.
What changes at team scale?
With one agent, MCP is a config file: a list of servers, each with its own credential. With several people on several clients, the same list is copied for each pair, each copy with its own credentials, and nothing ties them together. There is no shared view of who did what or what it cost.
One remote server changes the shape of each concern:
| Concern | Each agent configured alone | One remote server for the org |
|---|---|---|
| App credentials | Each client holds a token | The org holds the connection; the agent receives tools, never the token |
| Who can act through an account | Whoever has the token | Private to one member, or shared with the org |
| Permissions | A guard inside each client | One policy, judged in front of the tools, for every client |
| Cost | Per-provider bills | One ledger, in credits, with spend caps on keys |
| Record | Per-client logs | One activity trail per org |
Shared connections: a connection is private or shared. A shared Slack workspace or a shared Linear app serves everyone; a personal Gmail stays private. Agent principals reach shared connections only. The connectors page covers the account model.
One policy: Smart Approval is one plain-English text an admin writes, judged against every write any agent makes through the server. Reads are never gated. It sees only calls made through CoreSpeed; a local server next to the client is outside it.
One ledger, one trail: every metered call is charged in credits in the org ledger, and recorded in Dashboard → Activity with action, actor, outcome and cost. Memory is org-owned as well, scoped private or shared, and costs 0 credits per call.
Which clients can connect?
Any client that speaks MCP over Streamable HTTP. The documented ones are Claude Code, Codex, Cursor, Copilot in VS Code, OpenClaw, Hermes, claude.ai and Claude Desktop as a custom connector on Pro, Max, Team and Enterprise plans, ChatGPT as a custom connector under Developer mode on Plus and Pro on the web, and any client with an mcpServers map:
{ "mcpServers": { "corespeed": { "type": "http", "url": "https://api.corespeed.io/mcp" } } }For Claude Code the same entry is claude mcp add corespeed https://api.corespeed.io/mcp --transport http --scope user. Add it at user scope, so it applies to every project, and add it once; a second corespeed entry would collide on tool names.
What does the list of tools mean for a team?
tools/list on CoreSpeed is caller-specific. It returns exactly what this sign-in can call: the capabilities on for this member, the connectors this member or the org connected, the manage tools this credential may use. Two teammates get two different lists. An agent key gets the shared connections only. A tool missing is a decision somewhere, usually an app not yet connected. The MCP page describes the surface, and the Introducing CoreSpeed post explains why one server carries all of it.
FAQ
Is MCP specific to one model vendor? No. It is an open protocol, and the clients listed above come from several vendors.
Do I still need local MCP servers? A single-tool local server is fine for one person on one machine. The remote server is for what the team shares: app accounts, memory, policy and the bill.
Does CoreSpeed run my agents? No. CoreSpeed equips the agent you already run. Your client, or an unattended job you operate, makes the calls.
Is tools/list metered? No. Discovery and memory operations cost 0 credits.
Can the server batch requests? No. The transport is one JSON-RPC call per HTTP request; batches are rejected.