Pickaxe MCP Server

Connect Claude Code, Codex, Cursor, VS Code, or any other MCP client straight to your Pickaxe workspace. Your agents, documents, users, and access groups become tools your AI client can use — no local install, no custom integration code.

---

What is the Pickaxe MCP Server?

MCP (Model Context Protocol) is the standard way AI clients discover and call outside tools. The Pickaxe MCP Server puts your whole workspace behind that standard: point a client at your workspace URL, authenticate with a Workspace API Key, and every Pickaxe Workspace API operation shows up as a tool the client can call.

Each workspace gets its own address:

https://mcp.pickaxe.co/YOUR_WORKSPACE_ID

It's a hosted HTTP server, so there's nothing to install or keep running. If your client speaks MCP over HTTP, it can talk to Pickaxe.

---

Setting it up

Go to your workspace, open Settings, and find the Workspace API Keys section. Underneath the key table you'll see a panel called Connect an MCP client. Expand it and you get a two-step setup.

1. Choose your connection. Pick your MCP client and the Workspace API key you want it to use. Only keys with the Use toggle switched on appear in the list — if the dropdown says "No enabled API key," enable one (or hit Create to make a new one) first.

Pickaxe formats the setup for five options:

2. Copy your configuration. The panel writes the whole snippet for you — server URL, headers, and all. Hit Copy setup and paste it where your client expects it.

For Claude Code, that's a single terminal command:

claude mcp add --transport http --scope user pickaxe "https://mcp.pickaxe.co/YOUR_WORKSPACE_ID" --header "Authorization: Bearer YOUR_WORKSPACE_API_KEY"

For a JSON-configured client like Cursor, it looks like this:

{
  "mcpServers": {
    "pickaxe": {
      "url": "https://mcp.pickaxe.co/YOUR_WORKSPACE_ID",
      "headers": { "Authorization": "Bearer YOUR_WORKSPACE_API_KEY" }
    }
  }
}

One detail worth knowing: your key is hidden in the on-screen preview and only included when you copy. The panel is safe to screen-share; the clipboard is not.

Working across several workspaces? Add one MCP server entry per workspace, each with that workspace's own URL and key.

---

What your AI client can do

Once connected, your client can see and act on everything the Workspace API covers:

• Agents — list them, read their configuration, create new ones, update prompts, and kick off builds
• Knowledge base — upload documents, connect and disconnect them from agents, update or delete them
• Deployments — list, update, and delete deployments, including Meeting Bot sessions and calendar connections
• Users — create users, look them up, update or remove them, and check scheduled follow-ups
• Memory — read, write, and clear workspace memories and per-user memories
• Access Groups — create groups, assign and remove users, preview a deletion before committing to it
• Portals and Pages — create and restyle portals, manage pages and portal links
• Actions — list available actions and their runs, connect and disconnect them
• Models and products — list the models available to your workspace and the products configured on it

That's the same surface area the Pickaxe CLI and Wingman work through — the MCP Server just hands it to your own AI client directly.

---

Running an agent from your MCP client

Alongside the API tools there's one purpose-built tool: run_pickaxe_completion.

Give it an agent's ID and a message, and it runs that agent and returns the response. The useful part is what it doesn't require — the agent does not need an API deployment. Any agent in the workspace can be run this way, which makes it easy to have your coding agent test a prompt change, spot-check an answer, or chain a Pickaxe agent into a larger workflow without deploying anything first.

You can pass a message, structured inputs, a user ID, a conversation ID, image URLs, and metadata — the same shape as a normal completion request.

---

How access is scoped

The MCP Server checks three things on every request:

1. The key is a valid Workspace API Key. OAuth access tokens are deliberately not accepted here.
2. The key is enabled and belongs to the workspace in the URL. A key from another workspace is rejected, and flipping a key's Use toggle off cuts the connection immediately.
3. The target belongs to the workspace. Asking run_pickaxe_completion to run an agent from a different workspace fails.

Because the connection is scoped to one workspace, an AI client configured for a client project can't reach into your other workspaces.

A workspace API key is powerful — it can create, modify, and delete real workspace data. Treat it like a password: keep it out of shared repos and screenshots, give different tools their own keys so you can revoke one without breaking the rest, and turn a key off the moment you're done with it.

---

MCP Server, CLI, or Wingman?

All three drive the same workspace. Pick based on where you want to be working:

• MCP Server — you already work in Claude Code, Codex, Cursor, or VS Code and want Pickaxe available as tools in that client, next to everything else it can do.
• Pickaxe CLI — you want a coding agent to pull your workspace down locally, work on files, and push changes back.
• Wingman — you'd rather not leave Pickaxe at all. It's the same power, one click away inside your workspace.

Plenty of builders use more than one. They don't conflict.

---

Learn more

The full list of operations, request bodies, and examples lives in the Pickaxe API documentation — every endpoint there is a tool on the MCP Server.