Quickstart

The first run has one goal: keep the agent disposable while its access and context remain on the server. Nothing to paste, nothing to rotate.

1. Add CoreSpeed to your MCP client

Point the client at the endpoint and let it sign you in. On the first call the client receives a 401 advertising CoreSpeed's authorization server, opens your browser, and stores the token itself.

Sign in to the dashboard once before your first connection — that visit creates your workspace. If the client signed in before the workspace existed, sign in again from the client to pick it up.

Cursor

Installs the server and signs in on first use.

Add to Cursor

VS Code

Installs through the vscode:mcp/install handler.

Add to VS Code

Everything else takes one command or one config block — no install link exists for these clients:

claude mcp add --scope user --transport http corespeed https://api.corespeed.io/mcp

--scope user makes the server available in every project. Without it, claude mcp add defaults to local scope and registers the server for the current directory only.

Then run /mcp inside Claude Code and pick corespeed to complete browser sign-in.

codex mcp add corespeed --url https://api.corespeed.io/mcp
codex mcp login corespeed

add registers the endpoint; login completes browser sign-in. Run both — add finishes the OAuth flow on its own only when the endpoint already advertises it, and login is also how you re-authenticate later.

A URL and no credential. Any client that implements MCP OAuth discovers the rest from the 401:

MCP configuration

{
  "mcpServers": {
    "corespeed": {
      "type": "http",
      "url": "https://api.corespeed.io/mcp"
    }
  }
}

Headless clients, CI, and any client without OAuth support send a long-lived CoreSpeed key instead. Create one in Dashboard → Keys.

MCP configuration

{
  "mcpServers": {
    "corespeed": {
      "type": "http",
      "url": "https://api.corespeed.io/mcp",
      "headers": {
        "Authorization": "Bearer sk-cs-..."
      }
    }
  }
}

Replace sk-cs-... before pasting. Keep the key out of source control and shared configuration files; a user session JWT works in the same header if you already have one.

2. Inspect available tools

Your client runs tools/list on its own after connecting — the tools it shows are the whole callable surface, and no further setup is needed to see them.

What appears there is decided by the authenticated user and organization, not by your configuration:

Names are namespaced capability__operation, so memory__remember and notion__create_page read the same way in every client.
Before any connector is attached you already have the enabled built-in tools — memory and Media.
Account-management tools (manage__*) appear in the list, but the session-gated ones run only under a signed-in user session; called with an API key they return a jwt_session_required error instead of executing. The manage__remote_* lifecycle tools are the exception and do accept API keys.
tools/list is the authority. If a tool is absent, this caller cannot invoke it — capability settings and connected accounts are already applied.

The wire-level request, response fields, and error shapes are in the tools/list reference.

3. Connect software in the dashboard

Open Dashboard → Connectors, choose a connector, and authorize an account. The OAuth token stays with CoreSpeed; the agent receives callable tools, not the provider credential.

Your client's tool list now includes that provider's namespaced tools on the same endpoint. You do not add another MCP server.

4. Use a connector and memory

Ask the client to perform a task with the connected account, then preserve one piece of context for the next run. For example:

Read the launch thread from our connected X account, save the decision brief
to Notion, then remember that rollout requires a two-day review window.

Now open a different MCP client with the same CoreSpeed identity and ask it to search memory. The software connection and durable context are both still there — neither setup is repeated.