Graphite MCP server: two tools, one runs commands
Two tools. One of them runs any gt command. Its description tells the agent to stop using git commit.
Last verified 27 August 2026 · from The Graphite CLI on npm and the server's own tools/list response
This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.
Summary
Graphite's MCP server is built into its command line rather than shipped separately, and it ties Helicone for the smallest tool list in this guide: 2 tools, run_gt_cmd and learn_gt.
The count is misleading. run_gt_cmd takes an arbitrary argument array and a working directory, so it is a general executor for the gt command line rather than a single capability.
Its description is 3,077 characters and reads as instructions to the model. It tells the agent to assume stacked pull requests. It replaces git commit with gt create, and git push with gt submit --no-interactive.
What is the Graphite MCP server?
It is Graphite's server for the Model Context Protocol. Graphite is a stacked pull-request workflow: each branch sits on top of the one below it, and gt submit opens a pull request for each branch in the stack. The server exposes that workflow through the CLI rather than through an API.
run_gt_cmd requires three arguments. args is an array passed straight to gt. cwd is an absolute project path. why is a one-line explanation of the command. That last field is unusual and exists to make the agent state intent.
learn_gt carries a 44-character description. The tool returns an explanation of stacking. It is documentation, not an operation.
Graphite brings stacked pull-request work into the agent's code-review view. Its release connection stops at opening the pull request; the product has no wider runtime or cost surface here.
| Part of the work | What Graphite has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | Stacked pull requests, branch management | Yes. Core strength, through whatever gt subcommand the agent chooses to run |
| CI & release | Pull request submission | Partial. gt submit opens and updates pull requests; there is no pipeline or deployment surface |
| Production observability | None | No metrics, logs or traces from running services |
| Agent observability & evals | None | No traces, evaluations or prompt versioning for your own agents |
| AI cost management | None | No spend data of any kind |
In practice, Graphite changes how work is committed rather than answering questions about it. The connector is a way to act, not a way to read. Nothing here reports on a build, a service or a cost, so every other stage needs its own connector.
What can an AI agent do with Graphite?
| Task | Tools | Works | Watch out for |
|---|---|---|---|
| Create a branch and commit | run_gt_cmd | Yes | The description instructs the agent to use gt create rather than git commit |
| Submit a stack for review | run_gt_cmd | Yes | gt submit --no-interactive pushes and opens pull requests without prompting |
| Restack after a change | run_gt_cmd | Yes | Any gt subcommand is reachable through the same tool |
| Understand the stacking model | learn_gt | Yes | It returns an explanation, not the state of your repository |
| Read a pull request's review comments | GitHub | No, separate server | This connector runs the CLI; it does not query a review API |
| See whether CI passed | CircleCI, GitHub or Harness | No, separate server | Nothing here reports build status |
Every row that works uses the same tool. There is no schema-discovery call here: run_gt_cmd takes an argument array, so the agent has to know the gt subcommand before it calls anything. An allowlist that approves run_gt_cmd approves every gt subcommand at once, including submission.
2 tools registered, both on by default
- Acting1Write
run_gt_cmd- Explaining1
learn_gt
run_gt_cmd requires args, cwd and why. The first is an array passed straight to the gt command line, so the tool's reach is the CLI's reach. Counted on 24 August 2026 from the released CLI.
What connecting costs before the first question
A context window is the amount of text a model can hold at once, and connecting uses some of it before the agent asks anything. Every tool the server registers sends its name, description and input schema to the model when the session starts. The tool list is charged whether or not a single tool is called.
2 tools cost between 954 and 1,770 tokens. BuildPulse registers five tools and costs less. Tool count is not context cost.
Descriptions average 1,561 characters across the two, and run_gt_cmd carries 3,077 of them. The schemas are small at 307 characters, because one array and two strings is the whole interface.
| Tool set | Tools | Tokens (GPT-5.6, GPT-5.5) | Tokens (GPT-4, GPT-3.5) | Tokens (Claude Haiku 4.5 to Opus 5) | Share of a 200,000-token window |
|---|---|---|---|---|---|
| Every tool, as registered | 2 | 954 to 1,044 | 956 to 1,048 | 1,596 to 1,770 | 0.5% to 0.9% |
Encodings: GPT-5.6, GPT-5.5 o200k_base; GPT-4, GPT-3.5 cl100k_base; Claude Haiku 4.5 to Opus 5 count_tokens. Counted 24 August 2026 from tools/list on the released CLI 1.8.6 from npm. It was started with gt mcp locally.
Registration is static, so no Graphite account was involved. Figures cover name, description and input schema. The two models in column one share the o200k_base encoding, so they get one count. The spread is formatting, about 10%. Reasoning tokens are output, spent per request. This count is input, charged once at connection.
The Claude figures are measured rather than encoded. Anthropic publishes no local tokenizer. The definitions were sent to the API's count_tokens endpoint, and a no-tools baseline was subtracted. The range covers two tokenizer generations rather than two serializations. Haiku 4.5 and Opus 4.6 sit at the low end. Opus 5 and Sonnet 5 sit at the high end. The gap between them is about a tenth.
Graphite MCP server limits: where answers come back incomplete
Two limits follow below. One comes from one tool standing in for an entire command line. The other comes from that tool's description.
The agent says: “I used the Graphite tool.” That names nothing about what happened.
run_gt_cmd accepts any argument array, so a transcript showing one tool call could be a status check or a submission that opened three pull requests.
There is no second tool to approve or refuse separately, because the server registers only two and the other returns documentation.
cwd is required, must be absolute, and is rejected by the schema before gt runs.
Guard: Require the agent to quote the full command and the working directory, and use the required why field as the record.
The tool description changes how the agent commits, not just what it can call.
The 3,077-character description instructs the model to assume a stack of pull requests. It asks the agent to present that stack before writing code.
It also replaces the usual commands: gt create instead of git commit, and gt submit --no-interactive instead of git push.
Guard: Connect this only on repositories where the Graphite workflow is the agreed one, because the instruction applies to the whole session.
How to configure Graphite MCP for agents
- 1
Treat
run_gt_cmdas shell access togtIt accepts any argument array, so approving it once approves every subcommand, including submission.
- 2
Read the description before connecting
It instructs the agent to assume a stack of pull requests and to stop using
git commitandgit push. - 3
Set the working directory deliberately
cwdis required and must be absolute, which means the agent names the repository it acts on. - 4
Expect the
whyfield to be the audit trailThe tool requires a one-line reason for every command, which is the only record of intent the interface provides.
Paste this into your agent’s instructions
One tool covers every operation, so the tool name in a transcript says nothing about what happened. The block makes the agent name the command.
When you answer using Graphite MCP tools, state: - The exact gt command you ran, including every argument. - The absolute working directory it ran in. - Whether the command pushed or opened a pull request. gt submit --no-interactive does both without prompting. Never state that data does not exist. State that the command above produced no output. Write your answer in ASD-STE100 Simplified Technical English. Use short sentences with one idea in each.
Do you need the MCP server at all?
Not when a person is deciding the structure. Graphite's gt command is the direct alternative, and in a terminal it performs the same work while a person decides each step.
The connector earns its place when the agent is writing the code as well as committing it, because the stack structure can then follow the work rather than be reconstructed afterwards.
For reading pull requests, reviews and CI status, a repository connector answers questions this one cannot, since nothing here queries an API.
Connect it when the agent is authoring stacked changes. Use the terminal when a person is deciding the structure.
Graphite MCP server setup
There is no separate package. Installing the Graphite CLI installs the server, and gt mcp starts it.
Authentication is the CLI's own stored session, so a machine where gt auth has already run needs no credential in the configuration.
Claude Code
No credentials appear here. The CLI's stored session is used, so authorize once in a terminal before connecting.
claude mcp add-json "graphite" '{"command":"npx",
"args":["-y","@withgraphite/graphite-cli","mcp"]}'Cursor
In ~/.cursor/mcp.json. Again no credentials: the CLI holds the session.
{"mcpServers":{"graphite":{"command":"npx",
"args":["-y","@withgraphite/graphite-cli","mcp"]}}}Codex CLI
Codex reads TOML, so the JSON blocks above will not transfer. No credentials belong here either.
[mcp_servers.graphite] command = "npx" args = ["-y", "@withgraphite/graphite-cli", "mcp"]
Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Claude Desktop
macOS ~/Library/Application Support/Claude/claude_desktop_config.json. Windows %APPDATA%\Claude\claude_desktop_config.json. There is no CLI. Edit through Settings, Developer, Edit Config.
Quit and restart fully for changes to load. Paths in args must be absolute. Logs at ~/Library/Logs/Claude/mcp.log.
No credentials appear in the file. The CLI's own stored session is used, so authorize once with gt auth first.
{"mcpServers":{"graphite":{"command":"npx",
"args":["-y","@withgraphite/graphite-cli","mcp"]}}}Gemini CLI
~/.gemini/settings.json globally, or .gemini/settings.json per project. Key mcpServers. CLI: gemini mcp add.
No credentials appear in the file. The CLI's own stored session is used, so authorize once with gt auth first.
{"mcpServers":{"graphite":{"command":"npx",
"args":["-y","@withgraphite/graphite-cli","mcp"]}}}VS Code Copilot
.vscode/mcp.json per workspace, or your user profile. CLI: code --add-mcp.
No credentials appear in the file. The CLI's own stored session is used, so authorize once with gt auth first.
{"servers":{"graphite":{"command":"npx",
"args":["-y","@withgraphite/graphite-cli","mcp"]}}}The key is `servers`, not `mcpServers`. VS Code is the only client that uses that name, and copying a config from anywhere else fails silently.
Windsurf
~/.codeium/windsurf/mcp_config.json, which is the path Windsurf documents. Key mcpServers, the same JSON shape as Cursor, carrying the same CLI session, with no credential in the file.
Zed
~/.config/zed/settings.json, carrying the same CLI session, with no credential in the file, as in the blocks above.
The key is `context_servers`. Zed does not call them MCP servers in config, so searching its settings for mcp finds nothing.
Google Antigravity
~/.gemini/config/mcp_config.json globally, or .agents/mcp_config.json per project. Key mcpServers. There is no CLI. Use the /mcp overlay in the editor. Supports stdio, streamable HTTP, SSE and websocket.
No credentials appear in the file. The CLI's own stored session is used, so authorize once with gt auth first.
{"mcpServers":{"graphite":{"command":"npx",
"args":["-y","@withgraphite/graphite-cli","mcp"]}}}Amp (Sourcegraph)
~/.config/amp/settings.json or .amp/settings.json, carrying the same CLI session, with no credential in the file. The amp mcp CLI covers approve, doctor and oauth.
The key is `amp.mcpServers`, namespaced. A bare mcpServers block is ignored.
Cline
~/.cline/mcp.json per the docs. The source also reads ~/.cline/data/settings/cline_mcp_settings.json. Key mcpServers, standard JSON shape, carrying the same CLI session, with no credential in the file. Supports stdio, streamable HTTP and SSE.
Goose (Block)
~/.config/goose/config.yaml, carrying the same CLI session, with no credential in the file.
YAML, and servers are called `extensions`. Goose does not use the MCP vocabulary in config at all. Add one interactively with goose configure, or per session with goose session --with-extension.
Kiro (AWS)
.kiro/settings/mcp.json per workspace, or ~/.kiro/settings/mcp.json globally. Key mcpServers, standard JSON shape, carrying the same CLI session, with no credential in the file.
Warp
~/.warp/.mcp.json or .warp/.mcp.json. Key mcpServers, standard shape, carrying the same CLI session, with no credential in the file. Also addable through the /agent-add-mcp skill.
JetBrains Junie
.junie/mcp/mcp.json per project, or ~/.junie/mcp/mcp.json. Key mcpServers, carrying the same CLI session, with no credential in the file. Use /mcp in the CLI to manage.
Roo Code
.roo/mcp.json per project. The global file is mcp_settings.json, opened from the Roo Code MCP settings view with Edit Global MCP. Key mcpServers, carrying the same CLI session, with no credential in the file.
Continue
.continue/mcpServers/*.yaml, one file per server, carrying the same CLI session, with no credential in the file.
YAML, and `mcpServers` is a list, not an object. Every JSON client keys servers by name. Continue takes an array, so a converted config will not parse.
Trae
.trae/mcp.json per project, or paste into the UI under Raw Config (JSON). Key mcpServers, standard shape, carrying the same CLI session, with no credential in the file.
Devin
Devin has no config file to edit. Servers are added through a web form in the settings UI, and Devin's documentation states you do not need to write or paste JSON. The block below is the shape those fields describe, shown for reference. Either route uses the same CLI session.
Installed CLI rather than npx
If gt is already on the path, call it directly. It authorizes from its own stored session.
{"mcpServers":{"graphite":{"command":"gt",
"args":["mcp"]}}}Read-only access, permissions and security
One tool executes commands
run_gt_cmdpasses an argument array togt, so its reach is whatever the CLI can do in the given directory.Submission is one of those commands
The tool's own description directs the agent to
gt submit --no-interactive, which pushes branches and opens pull requests without a prompt.The description is instruction, not documentation
It tells the model to assume stacked pull requests and to avoid
git commitandgit push, which changes behavior beyond this connector.Client approval is all-or-nothing
There is no second tool to approve separately, so an allowlist cannot separate a restack from a submission.
Troubleshooting
- A command fails with a path error
cwdis required and must be an absolute path to the project root. A relative path is rejected by the schema.- The agent stopped using git commit
- That is the tool description working as written. It instructs the model to use
gt createinstead ofgit commitandgt submit --no-interactiveinstead ofgit push. - A pull request was opened unexpectedly
gt submit --no-interactivesubmits the current branch and everything below it in the stack. It is reachable through the same tool as every other command.- Authentication is missing
- The server uses the CLI's stored session. Run
gt authin a terminal; nothing in the MCP configuration carries a credential.
Graphite MCP server: Reference
| Item | Value |
|---|---|
| Status | Graphite CLI 1.8.6 on npm |
| Source | No public repository for the CLI |
| Package | @withgraphite/graphite-cli; the server is gt mcp |
| Auth | The CLI's own stored session |
| Tools | 2, both on by default |
| Required arguments | args, cwd and why on run_gt_cmd |
| Largest description | 3,077 characters, on run_gt_cmd |
| Context cost | 954 to 1,770 tokens |
What engineers report
There is no public repository for the CLI, so the package and the wire capture are the only primary sources.
| What was checked | What it shows |
|---|---|
| Package version | 1.8.6 on npm |
| Public repository | None found for the CLI |
Tools returned by tools/list | 2 |
| Average description | 1,561 characters per tool |
| Largest description | 3,077 characters, on run_gt_cmd |
| Average schema size | 307 characters per tool |
npm facts retrieved 24 August 2026. A GitHub lookup for a withgraphite/graphite-cli repository returned not found on the same date, so no repository facts are claimed. Tool counts and description sizes come from the released CLI's own tools/list response.
Should you connect an agent to Graphite?
Yes. Best for repositories where stacked pull requests are the agreed workflow, since the description enforces that assumption.
- Strongest fit
- Teams already on Graphite whose agents write code and are expected to structure it as a stack.
- Main advantage
- The whole
gtcommand line is reachable in one call, with a required reason field on every command. - Main weakness
- One tool covers every operation, so a client allowlist cannot separate reading from submitting.
- Operational risk
gt submit --no-interactivepushes branches and opens pull requests, and the tool's own description directs the agent to it.
From Oodle
One platform for agent traces and infrastructure
Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface, from $10 per million spans.
See agent observabilityFrequently asked questions
How many tools does the Graphite MCP server have?
2, both on by default. Counted from the CLI's own tools/list response on version 1.8.6, on 24 August 2026.
What does run_gt_cmd actually do?
It runs any gt subcommand. It requires an argument array, an absolute working directory and a one-line reason for the command.
Why do two tools cost about 954 tokens?
The descriptions are long. run_gt_cmd carries 3,077 characters, most of which instructs the model on how to structure and submit work.
Will it change how my agent uses git?
Yes. The description tells the model to use gt create instead of git commit and gt submit --no-interactive instead of git push.
Can I approve reading but not submitting?
Not through a client allowlist. Both are the same tool with different arguments, so the approval covers everything gt can do.