Claude Code, Codex and other MCP clients

parsemend mcp serves Parsemend to an agent session over the Model Context Protocol. It is a local stdio server: your MCP client launches parsemend mcp as a child process on your machine and talks to it over that process's stdin and stdout. There is no URL to paste, no port, and no OAuth consent screen — it authenticates with the token parsemend login already stored.

That inverts parsemend fix. There, the CLI owns the loop and spawns a model. Here the session owns the loop and Parsemend supplies the context, which means the session's own model does the work, its own tools read and edit the code, and it can stop and ask you something halfway through.

Register the server

Once per machine.

Claude Code

claude mcp add parsemend -- parsemend mcp

Codex

codex mcp add parsemend -- parsemend mcp

Other clients

{
  "mcpServers": {
    "parsemend": {
      "command": "parsemend",
      "args": ["mcp"]
    }
  }
}

Claude Code and Codex are the two clients the CLI is documented against. Any client that can launch a local stdio MCP server should work from the JSON stanza above — that is protocol compatibility we expect rather than a configuration we ship and test, so treat the exact key names as your client's business, not ours.

In Claude Code, /mcp lists the connected servers and their tools. Four tools under parsemend means it is wired up.

Which repository it works in

The server works against the directory the session launched in. If you drive several repositories from one session, or your client starts elsewhere, pin it:

claude mcp add parsemend -- parsemend mcp --cwd /path/to/repo

This matters for two tools only. list_issues and get_issue_context talk to Parsemend and do not care where you are; analyze_issue and post_back read the checkout.

A session, start to finish

/model opus-5
> fix postlyra-12

What happens, in order:

1. The session calls get_issue_context for postlyra-12 and gets the exception, stack frames, sample events with breadcrumbs, connected errors, the trace tree, related logs, and how the stack paths map onto this repository.
2. It reads the files those frames point at, with its own tools. Parsemend is not involved and no source is sent anywhere.
3. It proposes a change and edits the working copy. You review it the way you review anything else that session writes.
4. If you ask it to, it calls post_back and the fix appears on the issue.

Step 4 is opt-in by design. Nothing is published unless you say so.

The four tools

Tool	Arguments	What it does
list_issues	project, status, limit	The same list as parsemend issues, most recently seen first. Each row carries the short_id the other tools take.
get_issue_context	issue, include	The whole debugging bundle, or named sections of it. Makes no model call. See the context bundle.
analyze_issue	issue, model, skip_plan	Optional. Runs Parsemend's own root-cause explorer over this repository and turns the result into a plan.
post_back	issue, summary	Publishes what you changed, read back from git diff.

What each one costs

get_issue_context and list_issues are API calls. They spend no model tokens beyond the session's own reading of the result.

analyze_issue is the exception: it runs Parsemend's explorer against the provider API key configured in the CLI, not your session's model. It exists for when you specifically want Parsemend's analysis rather than your own — reasoning it out in the session is usually the better trade, and costs nothing extra. Its result is recorded locally, so a later post_back publishes the analysis alongside the diff.

post_back is the only tool that sends anything out of the machine. The tool description tells the session to ask you first.

Publishing a fix

> post that back to the issue

post_back runs git diff HEAD, turns each changed file into a diff, and publishes it to the issue as a fix run — visible in the panel under AI Agent → Fix runs and on the issue itself. The summary argument becomes the commit message recorded with it.

The mechanism is also the catch: git diff HEAD sees staged and unstaged changes, and nothing else. Commit the work first and post_back publishes an empty change set. Create a new file and it stays invisible until you git add it. Publish before you commit, and git add anything new.

When the working tree is unchanged and no analysis has been run for that issue, post_back publishes nothing and says so rather than filing an empty run.

Two things it deliberately does not do: it never opens a pull request, and it records no executor for the run, because the session that did the work is neither of the two the server knows about. Recording nothing beats recording the wrong thing.

Helping the session find the code

get_issue_context includes code_mappings, which translate a stack-frame path like /var/www/html/app/Models/Post.php into a repo-relative app/Models/Post.php. Without them the session gets the frames but has to locate the files by searching.

Set them up in the panel under Settings → Projects → your project → Code mappings. If the project has a repository connected, Suggest from repo derives them for you.

Files the tools write

analyze_issue and post_back keep run state in .parsemend/run-<id>.json inside the repository, so a session that analysed an issue yesterday can publish that analysis today. Add it to .gitignore:

.parsemend/

Untracked files are invisible to git diff HEAD, so an un-ignored .parsemend/ will not leak into a post_back either way. Ignoring it just keeps git status honest.

When something is wrong

The server prints one startup line to stderr and speaks protocol on stdout, so a client that shows no tools is usually a client that has not restarted, or a parsemend that is not on the PATH the client uses. More in troubleshooting.