---
source: CrewKit documentation
url: https://crewkit.io/docs/mcp.md
title: "MCP server"
description: "Expose your project's institutional memory to any MCP-capable agent with crewkit mcp serve."
---


crewkit works with Claude Code today — and any MCP-capable agent can pull project context through the crewkit MCP server. Project memory, conventions, prior work, active work, and blueprint state become tools the agent can call mid-session.

---

## Automatic registration

Sessions launched with `crewkit code` register the crewkit MCP server automatically — there is nothing to configure. The tools below are available in every session.

---

## Manual registration

`crewkit mcp serve` runs a stdio MCP server. Register it in any MCP-capable client:

```json
{
  "mcpServers": {
    "crewkit": {
      "command": "crewkit",
      "args": ["mcp", "serve"]
    }
  }
}
```

The server resolves your organization and project from the git remote of the working directory. Override when that's not possible:

```bash
crewkit mcp serve --org <org-id> --project <project-id>
```

Or via the `CREWKIT_ORG_ID` and `CREWKIT_PROJECT_ID` environment variables.

Authentication uses your CLI login (`crewkit auth login`). If you're signed out, tool calls return an actionable error instead of failing silently.

Every tool call also requires that the signed-in user has accepted the current acceptable-use policy. Until that acceptance exists, calls return an actionable error, and the check fails closed — if the policy endpoint can't be reached, the call is refused rather than allowed through.

The server implements MCP 2026-07-28 (stateless lifecycle, `server/discover`) and remains compatible with clients speaking 2025-11-25 and earlier — including current Claude Code — via the standard `initialize` handshake. Both paths serve the same tools identically.

---

## Available tools

| Tool | What it does |
|------|--------------|
| `search_project_context` | Hybrid lexical + semantic search over project memory: uploaded docs, meeting transcripts, captured Slack messages, Drive imports, and indexed past sessions |
| `find_prior_work` | Find past conversations where someone already worked on something similar — avoid re-solving solved problems |
| `get_active_work` | Who's working on what right now: open conversations and claimed blueprint tasks, grouped by user |
| `get_conventions` | The playbook conventions that apply to this project's stack — coding standards, legacy patterns, severity-tiered rules |
| `get_blueprint_state` | The active blueprint: progress, epics, task statuses, and the caller's assigned tasks |
| `save_state` | Save a session handoff as your rolling personal save state (the agent is instructed to show it to you for approval first) |
| `load_state` | Load a save state: your personal handoff, or the most recent team digest |
| `share_update` | Broadcast a short, milestone-level update so teammates' sessions can avoid overlapping work |
| `add_note` | Write one durable note into project memory — a decision and its rationale, a constraint, a hard-won finding. The note is indexed and readable by everyone in the organization, and the agent is instructed to show it to you and get your approval before writing it |

`add_note` needs a `CREWKIT_LLM_SESSION_ID`, so it only works in a session launched by `crewkit code`. A hand-registered client calling it gets an error telling it to relaunch that way. Like `save_state` and `share_update`, it is a mutating tool and is deliberately left out of the pre-approved permission allow-list, so it always prompts.

---

## What this means in practice

Mid-session, an agent can ask "has anyone touched this before?", check which conventions govern a decision, see whether a teammate already claimed the task, and pick up exactly where the last session left off. crewkit's memory works wherever your agents do.

---

## Next steps

- [Artifacts and project memory](/docs/artifacts)
- [Blueprints](/docs/blueprints)
- [Playbooks](/docs/playbooks)