# GitWarren (npm · gitwarren)

Code review on your own machine, for you and your coding agent. Nothing leaves your computer.

- Trust score: 79/100 (medium)
- Change this week: +15
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-24

## Components

- npm · `gitwarren`: 79/100 (this document), [markdown](https://verifymcp.io/servers/klarluft-gitwarren/gitwarren.md), [page](https://verifymcp.io/servers/klarluft-gitwarren/gitwarren)

## Channel facts

- Registry: `npm`
- Package: `gitwarren`
- Version: `0.1.17`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-24.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 0 of 2 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 97/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to klarluft/gitwarren-app).
  - Clear OSI-approved license (GPL-3.0-or-later).
  - Actively maintained (last published 5 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 54/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 4702 tokens (~276/item across 17 items; 17 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 30/100
  - Stability observed for 9 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 67/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 3 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 17 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the GitWarren MCP server?

GitWarren runs locally as an npm package, launched with npx -y gitwarren. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add klarluft-gitwarren -- npx -y gitwarren
```

### Cursor

```json
{
  "mcpServers": {
    "klarluft-gitwarren": {
      "command": "npx",
      "args": [
        "-y",
        "gitwarren"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "klarluft-gitwarren": {
      "command": "npx",
      "args": [
        "-y",
        "gitwarren"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add klarluft-gitwarren -- npx -y gitwarren
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "klarluft-gitwarren": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "gitwarren"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add klarluft-gitwarren --command npx --arg -y --arg gitwarren
```

### Hermes

```yaml
mcp_servers:
  klarluft-gitwarren:
    command: "npx"
    args: ["-y", "gitwarren"]
```

### Netclaw

```json
{
  "McpServers": {
    "klarluft-gitwarren": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "gitwarren"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add klarluft-gitwarren -t stdio -c npx -a -y gitwarren
```

### Other

```json
{
  "mcpServers": {
    "klarluft-gitwarren": {
      "command": "npx",
      "args": [
        "-y",
        "gitwarren"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-24 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-22 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-20 (score 77, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-18 (score 76, +12)

- [security regression] Stability: 0.07 → unverified
- [security regression] Tool safety: pass → unverified
- [security improvement] Known CVEs: unverified → pass
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional improvement] Dependency health: unverified → 1.00
- [functional] First check of Schema quality: unverified
- [functional] Package version: 0.1.16 → 0.1.17

### 2026-09-17 (score 64, +4)

- [security regression] Known CVEs: pass → unverified
- [security regression] Stability: 0.03 → unverified
- [security regression] Tool safety: pass → unverified
- [security improvement] Malware scan: unverified → pass
- [functional regression] Dependency health: 1.00 → unverified
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional] First check of Schema quality: unverified
- [functional] Package version: 0.1.14 → 0.1.16
- [functional] Package version: 0.1.14 → 0.1.15

### 2026-09-16 (score 60, +1)

- [functional regression] Schema quality: 244 → 276
- [functional improvement] Stability: unverified → 0.03
- [functional] Package version: 0.1.12 → 0.1.14
- [functional] Package version: 0.1.12 → 0.1.13

### 2026-09-15 (score 59)

First indexed and scored.

## MCP tools (17)

### `list_repositories` (~57 tokens)

List repositories

List every git repository tracked in GitWarren, each with its live git state (whether the folder still exists, whether it is still a repository, and the current branch). Git state is read fresh on every call and is never cached.

### `get_repository` (~28 tokens)

Get repository

Fetch one tracked repository by id, with its live git state.

Input parameters:

- `id` (integer, required)

### `add_repository` (~93 tokens)

Add repository

Start tracking a git repository. `path` may be any directory inside the working tree - it is resolved to the repository root before being stored, so the same repository cannot be added twice under two different paths. `name` defaults to the folder name. Fails with NOT_A_GIT_REPOSITORY if the path is not inside a git repository.

Input parameters:

- `name` (string)
- `path` (string, required)

### `update_repository` (~70 tokens)

Update repository

Rename a tracked repository, or repoint it at a moved working copy. Provide at least one of `name` or `path`. A new path is validated and resolved exactly as it is when adding.

Input parameters:

- `id` (integer, required)
- `name` (string)
- `path` (string)

### `remove_repository` (~38 tokens)

Remove repository

Stop tracking a repository. This only removes it from GitWarren - the working copy on disk is never touched.

Input parameters:

- `id` (integer, required)

### `list_reviews` (~367 tokens)

List reviews

List reviews, newest activity first. Filter with `repositoryId` and/or `status` ("open" or "closed"); omit both to list every review across all tracked repositories. A review records the two refs being compared, not the commits they resolved to - read the repository with git to see the actual changes.

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by `gitwarren serve` or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry `webUrl`. The two links are for two situations and neither replaces the other: `guiUrl` opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; `webUrl` opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer `webUrl` when the user is not at this machine, and both when you do not know.

Input parameters:

- `repositoryId` (integer)
- `status` (string)

### `get_review` (~325 tokens)

Get review

Fetch one review by id, with the repository it belongs to attached (including the repository path, so the changes can be inspected with git directly).

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by `gitwarren serve` or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry `webUrl`. The two links are for two situations and neither replaces the other: `guiUrl` opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; `webUrl` opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer `webUrl` when the user is not at this machine, and both when you do not know.

Input parameters:

- `id` (integer, required)

### `create_review` (~488 tokens)

Create review

Open a review comparing two refs in a tracked repository. `baseRef` is what the changes are measured against (usually the trunk) and `headRef` is the branch under review; the diff is taken from their merge base, like a pull request. Both refs must exist and share history, or the call fails with INVALID_INPUT. `title` defaults to "<head> into <base>". If the head branch is checked out in a worktree, its uncommitted changes are part of the review as well - a review can be opened on work that has never been committed. Passing the same ref as both endpoints is allowed and does exactly that: the review then holds only the uncommitted work on that ref, and its title defaults to "Uncommitted work on <ref>".

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by `gitwarren serve` or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry `webUrl`. The two links are for two situations and neither replaces the other: `guiUrl` opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; `webUrl` opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer `webUrl` when the user is not at this machine, and both when you do not know.

Input parameters:

- `baseRef` (string, required)
- `description` (string)
- `headRef` (string, required)
- `repositoryId` (integer, required)
- `title` (string)

### `update_review` (~376 tokens)

Update review

Change a review's title, description or endpoints, or set its `status` to "closed" or "open" again. Provide at least one field. New refs are validated exactly as they are on creation.

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by `gitwarren serve` or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry `webUrl`. The two links are for two situations and neither replaces the other: `guiUrl` opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; `webUrl` opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer `webUrl` when the user is not at this machine, and both when you do not know.

Input parameters:

- `baseRef` (string)
- `description` (string)
- `headRef` (string)
- `id` (integer, required)
- `status` (string)
- `title` (string)

### `remove_review` (~57 tokens)

Remove review

Delete a review. This removes only the review record - no branch, commit or file in the repository is touched. To file a finished review away without deleting it, set its status to "closed" instead.

Input parameters:

- `id` (integer, required)

### `agent_identity` (~105 tokens)

Agent identity

Show how comments from this session will be attributed, and optionally set a label for the session. The tool name ("Claude Code", "Codex", ...) is taken from the MCP handshake and cannot be changed - it is what makes attribution consistent across sessions. `label` is a short handle for *this* session ("auth-refactor"), worth setting when more than one agent is working the same review; it is remembered until this server process exits.

Input parameters:

- `label` (string)

### `list_review_comments` (~579 tokens)

List review comments

Every discussion on a review: review-level threads and line comments alike, each with its full message history and who wrote each message. Line threads also carry an `anchor` saying where they land in the code as it stands right now - "anchored" (the line is unchanged), "moved" (the code shifted and `anchor.line` is its current line) or "outdated" (the line is gone, so the comment may be about code that has since been rewritten). Threads about files the diff does not contain are resolved against those files at the head rather than against the patch, so a comment on unchanged code reports an honest anchor too. Check the anchor before acting on a line comment. An outdated one still carries `anchorSnapshot`, the code as it read when the comment was written, which is how to tell what was being objected to before it was rewritten.

A body may contain images, written as markdown pointing at a `gitwarren://attachment/...` URL - that is an internal token, not something to fetch. Each one is resolved in the comment's `attachments` array, where `path` is a real file on disk: read it with your own image tools. `alt` is the description whoever attached it wrote, and is worth reading first - it is often enough on its own, and it is all you get if you cannot see images.

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by `gitwarren serve` or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one th…

Input parameters:

- `reviewId` (integer, required)

### `add_review_comment` (~813 tokens)

Add review comment

Start a new discussion on a review. Omit `filePath` and `line` for a comment on the review as a whole; give both to attach it to a line, the way a pull-request review comment works. `side` picks which side of the diff `line` counts on - "head" (the default) for the code as it will be, "base" to remark on a line the change removed. Add `startLine` to comment on a block rather than a single line; `line` is then the last line of it, and the one the whole range follows if the code moves. The line is not required to be part of the diff. A line the patch does not print is looked up in the file itself at the head, so a remark on code this branch did not touch anchors and follows that code exactly as one on a changed line does - people read these in the review's Browse files tab. Only a line that is in neither the diff nor the file (past the end of it, or on the "base" side outside the patch) is kept without an anchor; the returned thread says which happened. Comments are attributed automatically from the MCP handshake - see `agent_identity`.

To include a screenshot, write the file to disk first, then reference it as an
ordinary markdown image:

    The dropdown renders behind the modal:

    ![dropdown behind modal](/tmp/dropdown-bug.png)

The file is copied into GitWarren and the path rewritten, so the image survives
/tmp being cleaned. Always write alt text - it is what agents without vision see.

If the path contains a space - "Screen Shot 2026-09-01 at 10.32.14.png", as macOS
names screenshots - wrap it in angle brackets, or markdown does not read it as an
image at all and it is left as plain text:

    ![login screen](</tmp/Screen Shot 2026-09-01 at 10.32.14.png>)

PNG, JPEG, GIF and WebP are accepted, up to 10 MB. A path that does not resolve is
left in the text as written rather than failing the call, so check the returned
body if it matters.

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it i…

Input parameters:

- `agentLabel` (string)
- `body` (string, required)
- `changes` (string)
- `filePath` (string)
- `line` (integer)
- `reviewId` (integer, required)
- `side` (string)
- `startLine` (integer)

### `reply_to_review_comment` (~569 tokens)

Reply to a review comment

Add a message to an existing thread. Use this rather than opening a new thread when responding to something someone already raised, so the discussion stays in one place. Thread ids come from `list_review_comments`.

To include a screenshot, write the file to disk first, then reference it as an
ordinary markdown image:

    The dropdown renders behind the modal:

    ![dropdown behind modal](/tmp/dropdown-bug.png)

The file is copied into GitWarren and the path rewritten, so the image survives
/tmp being cleaned. Always write alt text - it is what agents without vision see.

If the path contains a space - "Screen Shot 2026-09-01 at 10.32.14.png", as macOS
names screenshots - wrap it in angle brackets, or markdown does not read it as an
image at all and it is left as plain text:

    ![login screen](</tmp/Screen Shot 2026-09-01 at 10.32.14.png>)

PNG, JPEG, GIF and WebP are accepted, up to 10 MB. A path that does not resolve is
left in the text as written rather than failing the call, so check the returned
body if it matters.

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by `gitwarren serve` or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry `webUrl`. The two links are for two situations and neither replaces the other: `guiUrl` opens GitWarren on the machine the user is sitting at, which is t…

Input parameters:

- `agentLabel` (string)
- `body` (string, required)
- `threadId` (integer, required)

### `resolve_review_comment` (~350 tokens)

Resolve or reopen a thread

Mark a discussion settled, or reopen one. Set `resolved` to true once the point has been addressed, false to bring it back. Resolving records who did it; it never deletes the messages, which stay readable.

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by `gitwarren serve` or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry `webUrl`. The two links are for two situations and neither replaces the other: `guiUrl` opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; `webUrl` opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer `webUrl` when the user is not at this machine, and both when you do not know.

Input parameters:

- `resolved` (boolean, required)
- `threadId` (integer, required)

### `update_review_comment` (~335 tokens)

Edit a comment

Replace the text of one message. An agent can only edit messages written by its own tool - correcting yourself is expected, rewriting someone else's review is not.

Each result carries `guiUrl`, a link that opens this in GitWarren. Show it to the user - it exists to be clicked, and it is how they see this without going and finding it themselves. The link works whether or not GitWarren is running right now, so hand it over without checking anything. If the user says it will not open - the browser reports that the connection was refused - then GitWarren is not running on their machine, and starting it makes the same link work. When the page is served by `gitwarren serve` or by a plugin rather than by the app, the link also carries that launch's token, which the page exchanges for a cookie; a link minted before a restart says it needs a token, and the newest link is the one that works.

When this machine is reachable on the user's tailnet, results also carry `webUrl`. The two links are for two situations and neither replaces the other: `guiUrl` opens GitWarren on the machine the user is sitting at, which is the right one when that is this machine; `webUrl` opens the same review in a browser from any of their devices - a phone, a laptop across the room - because it names this machine on their tailnet. Offer `webUrl` when the user is not at this machine, and both when you do not know.

Input parameters:

- `body` (string, required)
- `id` (integer, required)

### `delete_review_comment` (~52 tokens)

Delete a comment

Delete one message. If it was the only message in its thread, the thread goes with it. As with editing, an agent can only delete messages written by its own tool.

Input parameters:

- `id` (integer, required)

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/klarluft-gitwarren/gitwarren#diagnostics

## Score history

- 2026-09-24: 79
- 2026-09-23: 78
- 2026-09-22: 78
- 2026-09-21: 77
- 2026-09-20: 77
- 2026-09-19: 76
- 2026-09-18: 76
- 2026-09-17: 64
- 2026-09-16: 60
- 2026-09-15: 59

## Common questions

### What is the GitWarren MCP server?

GitWarren is an MCP server listed in the public MCP registry as io.github.klarluft/gitwarren. Code review on your own machine, for you and your coding agent. Nothing leaves your computer. This page covers its npm package (gitwarren).

### Is the GitWarren MCP server safe to use?

GitWarren scores 79 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 24 September 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the GitWarren MCP server expose?

GitWarren exposes 17 tools: list_repositories, get_repository, add_repository, update_repository, remove_repository, and 12 more. Their descriptions and schemas cost roughly 4,702 tokens of context every time the server is loaded.

### Is the GitWarren MCP server still maintained?

GitWarren is still listed as active in the MCP registry. We last reached this channel on 24 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the GitWarren MCP server under?

GitWarren declares the GPL-3.0-or-later licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/gitwarren
- Socket report: https://socket.dev/npm/package/gitwarren
- Repository: https://github.com/klarluft/gitwarren-app
- Website: https://gitwarren.com/
- Changelog RSS feed: https://verifymcp.io/servers/klarluft-gitwarren/gitwarren.xml
- Changelog JSON feed: https://verifymcp.io/servers/klarluft-gitwarren/gitwarren.json
- HTML version of this page: https://verifymcp.io/servers/klarluft-gitwarren/gitwarren