NewAgent Observability is live.
Back to directory
Graphite logo

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.

Connector
Official, inside the Graphite CLI
Coverage
Stacked pull requests through the gt command line
Tools
2, both on by default
Biggest risk for an agent
One tool executes any gt subcommand, including submit

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 workWhat Graphite has hereCan an agent reach it
Code, tests & reviewStacked pull requests, branch managementYes. Core strength, through whatever gt subcommand the agent chooses to run
CI & releasePull request submissionPartial. gt submit opens and updates pull requests; there is no pipeline or deployment surface
Production observabilityNoneNo metrics, logs or traces from running services
Agent observability & evalsNoneNo traces, evaluations or prompt versioning for your own agents
AI cost managementNoneNo 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?

TaskToolsWorksWatch out for
Create a branch and commitrun_gt_cmdYesThe description instructs the agent to use gt create rather than git commit
Submit a stack for reviewrun_gt_cmdYesgt submit --no-interactive pushes and opens pull requests without prompting
Restack after a changerun_gt_cmdYesAny gt subcommand is reachable through the same tool
Understand the stacking modellearn_gtYesIt returns an explanation, not the state of your repository
Read a pull request's review commentsGitHubNo, separate serverThis connector runs the CLI; it does not query a review API
See whether CI passedCircleCI, GitHub or HarnessNo, separate serverNothing 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 setToolsTokens (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 registered2954 to 1,044956 to 1,0481,596 to 1,7700.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. 1

    Treat run_gt_cmd as shell access to gt

    It accepts any argument array, so approving it once approves every subcommand, including submission.

  2. 2

    Read the description before connecting

    It instructs the agent to assume a stack of pull requests and to stop using git commit and git push.

  3. 3

    Set the working directory deliberately

    cwd is required and must be absolute, which means the agent names the repository it acts on.

  4. 4

    Expect the why field to be the audit trail

    The 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.

Terminal
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.

Terminal
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.

Terminal
{"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.

Terminal
[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.

Terminal
{"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.

Terminal
{"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.

Terminal
{"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.

Terminal
{"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.

Terminal
{"mcpServers":{"graphite":{"command":"gt",
  "args":["mcp"]}}}

Read-only access, permissions and security

  • One tool executes commands

    run_gt_cmd passes an argument array to gt, 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 commit and git 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
cwd is 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 create instead of git commit and gt submit --no-interactive instead of git push.
A pull request was opened unexpectedly
gt submit --no-interactive submits 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 auth in a terminal; nothing in the MCP configuration carries a credential.

Graphite MCP server: Reference

ItemValue
StatusGraphite CLI 1.8.6 on npm
SourceNo public repository for the CLI
Package@withgraphite/graphite-cli; the server is gt mcp
AuthThe CLI's own stored session
Tools2, both on by default
Required argumentsargs, cwd and why on run_gt_cmd
Largest description3,077 characters, on run_gt_cmd
Context cost954 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 checkedWhat it shows
Package version1.8.6 on npm
Public repositoryNone found for the CLI
Tools returned by tools/list2
Average description1,561 characters per tool
Largest description3,077 characters, on run_gt_cmd
Average schema size307 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 gt command 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-interactive pushes 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 observability

Frequently 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.

Changelog

  • 5 May 2026. @withgraphite/graphite-cli 1.8.6 published to npm, the version carrying gt mcp.
  • 19 July 2023. The package first published to npm, at 0.20.36. It has 119 versions in total.

Sources

Every number on this page traces to one of these

  1. Package and version facts from npm · @withgraphite/graphite-cli 1.8.6, retrieved 24 August 2026
  2. Tool names, argument schema and description sizes from the CLI's own tools/list response
  3. Official MCP registry searched for Graphite on 27 August 2026, returning no results

Graphite’s own MCP documentation

Also code, tests and review:

For what happens after submission: