# What is MCP, explained for teams running several agents (/blog/what-is-the-model-context-protocol-for-teams)

![Illustration: Three small friendly robots with round camera-eye heads sit at one round table sharing one toolbox in the middle.](/blog/what-is-the-model-context-protocol-for-teams/hero.webp)

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.

**What an MCP client sends**

* 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

On CoreSpeed each call is one JSON-RPC message per HTTPS request to api.corespeed.io/mcp. Batches are rejected.

## How does MCP work on the wire? \[#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? \[#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](/docs/authentication) has the details.

## What changes at team scale? \[#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](/docs/connectors) 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? \[#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:

```json
{ "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? \[#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](/docs/mcp) describes the surface, and the [Introducing CoreSpeed](/blog/introducing-corespeed) post explains why one server carries all of it.

## FAQ \[#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.