> For the complete documentation index, see [llms.txt](https://docs.eesel.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eesel.ai/apis-and-developer-resources/claude-code-and-mcp-clients.md).

# Claude Code & MCP clients

Use eesel as an MCP server for Claude Code, Cursor or any MCP client, so you or an AI agent can chat with your agent and change its setup from the editor.

Your eesel workspace is also an MCP server. That means tools like Claude Code and Cursor can connect to it directly, so you (or an AI agent you're running) can talk to your agent, check activity, manage automations, and update your agent's setup without opening the dashboard.

It is a customer support MCP server that acts as your own agent, with its instructions, knowledge and connected tools, and with the same role you have in the dashboard. This page covers connecting with a token. For claude.ai and other assistants that sign in with OAuth, see [Use eesel from Claude and other AI assistants](/apis-and-developer-resources/use-eesel-from-claude-and-other-assistants.md).

## Set it up

Log in once, then ask the CLI for the connection details:

```bash
npx @eesel/cli login
npx @eesel/cli mcp token
```

`mcp token` prints the MCP URL, a 30-day workspace token, the headers, and a ready-to-paste line for Claude Code:

```bash
claude mcp add --transport http eesel "https://<api_url>/mcp" \
  --header "Authorization: Bearer <token>" \
  --header "X-Eesel-Agent-Id: <agent id>"
```

Restart Claude Code and run `claude mcp get eesel`. It should show as connected, and eesel's tools appear with an `mcp__eesel__` prefix.

Any other MCP client works the same way: it needs the server URL (`<api_url>/mcp`, HTTP transport), an `Authorization: Bearer <token>` header, and an `X-Eesel-Agent-Id` header naming the agent to act as. The `headers` object in the `mcp token` output is exactly that.

## Which agent am I talking to?

The token is scoped to your workspace; the `X-Eesel-Agent-Id` header picks which of your agents the client acts as. `eesel mcp token --agent <id-or-name>` prints the details for a specific agent; `eesel agents use <id-or-name>` sets the default. Switching agents is just a header change.

## What you can do

The client sees a small set of clean tools, named like the eesel CLI's commands, with the same permissions you have:

* `chat` talks to your agent. It answers from your connected sources, can take actions, and you can continue a conversation by passing its task id back. Anything not listed below - searching your knowledge, running an analysis, emailing someone - is something you ask the agent for here.
* `status` and `billing` show what's connected, whether its content is downloaded and up to date, and your plan and usage.
* `integrations` is everything about the tools your agent is wired to: what's connected, connecting more, downloading a source's content into eesel knowledge, and custom API access.
* `automations` and `instructions` manage what the agent does on its own and its standing rules.
* `files` lists, downloads, and uploads your own files - what you've added and what the agent has written for you. Connected sources' content (tickets, articles) isn't reachable here; the agent uses it when you ask in chat.
* `activity` lists recent runs and reads one in detail.
* `invite` adds a teammate.

Your role still applies:

* Anyone in the workspace can use the read tools: chat, activity, files, and the status views.
* Editors can also write: update instructions, manage automations and schedules, start downloads, invite teammates.
* Write actions follow the same approval rules as everywhere else. A tool set to ask for approval still asks, and the approval shows up in your dashboard as usual.

If a write action tells you it "only runs when the person who triggered this turn is verified as a workspace editor", your token predates your current role or was minted before write support. Mint a fresh one with `eesel mcp token` and update the header.

## Good to know

* Tokens last 30 days. Re-run `eesel mcp token` and update the header when one expires.
* The token carries your role at the time you minted it. If your role changes, re-mint.
* Tokens minted before this tool list shipped still show the older, longer list of internal tool names. Everything keeps working; re-mint with `eesel mcp token` to get the clean list.
* Treat the token like a password. Anyone holding it can act in your workspace for its lifetime.

## FAQ

<details>

<summary>How do I connect Claude Code to eesel?</summary>

Run `npx @eesel/cli login`, then `npx @eesel/cli mcp token`, and paste the `claude mcp add` line it prints. Restart Claude Code and run `claude mcp get eesel` to check it shows as connected.

</details>

<details>

<summary>Does eesel work with Cursor and other MCP clients?</summary>

Yes. Any MCP client works the same way: it needs the server URL (`<api_url>/mcp`, HTTP transport), an `Authorization: Bearer <token>` header and an `X-Eesel-Agent-Id` header. The `headers` object in the `mcp token` output is exactly that.

</details>

<details>

<summary>How long does an eesel MCP token last?</summary>

30 days. Re-run `eesel mcp token` and update the header when it expires, or when your role changes, because the token carries your role at the time you minted it.

</details>

<details>

<summary>Can the MCP client change my agent's setup?</summary>

Yes, if you are an editor. Editors can update instructions, manage automations and schedules, start downloads and invite teammates. Anyone in the workspace can use the read tools. Write actions follow the same approval rules as everywhere else.

</details>

<details>

<summary>How do I pick which eesel agent the client talks to?</summary>

Set the `X-Eesel-Agent-Id` header. `eesel mcp token --agent <id-or-name>` prints the details for a specific agent, and `eesel agents use <id-or-name>` sets the default.

</details>

<details>

<summary>Is the MCP token safe to share?</summary>

No. Treat it like a password. Anyone holding it can act in your workspace for its lifetime.

</details>

## Related

* [Use eesel from Claude and other AI assistants](/apis-and-developer-resources/use-eesel-from-claude-and-other-assistants.md) for claude.ai and OAuth sign-in
* [Use eesel from ChatGPT](/apis-and-developer-resources/use-eesel-from-chatgpt.md)
* [Set up from Claude Code or the terminal](/getting-started/set-up-from-a-coding-agent.md) for a full setup in commands
* [The eesel CLI](/apis-and-developer-resources/cli.md) for every command


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.eesel.ai/apis-and-developer-resources/claude-code-and-mcp-clients.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
