GitWarren
NPM · GITWARREN · SCANNED SEP 24
Code review on your own machine, for you and your coding agent. Nothing leaves your computer.
Available components
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. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 0 of 2 dependencies flagged as unhealthy. View diagnostics → Pass
Provenance & Transparency97
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to klarluft/gitwarren-app). View diagnostics → Pass
- Clear OSI-approved license (GPL-3.0-or-later).Pass
- Actively maintained (last published 5 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability54
- AI-judged instruction clarity (good).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management30
- Stability observed for 9 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage67
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 3 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 17 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
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.
npm · gitwarren
claude mcp add klarluft-gitwarren -- npx -y gitwarren
{
"mcpServers": {
"klarluft-gitwarren": {
"command": "npx",
"args": [
"-y",
"gitwarren"
]
}
}
} {
"servers": {
"klarluft-gitwarren": {
"command": "npx",
"args": [
"-y",
"gitwarren"
]
}
}
} codex mcp add klarluft-gitwarren -- npx -y gitwarren
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"klarluft-gitwarren": {
"type": "local",
"command": [
"npx",
"-y",
"gitwarren"
],
"enabled": true
}
}
} openclaw mcp add klarluft-gitwarren --command npx --arg -y --arg gitwarren
mcp_servers:
klarluft-gitwarren:
command: "npx"
args: ["-y", "gitwarren"] {
"McpServers": {
"klarluft-gitwarren": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"gitwarren"
]
}
}
} assistant mcp add klarluft-gitwarren -t stdio -c npx -a -y gitwarren
{
"mcpServers": {
"klarluft-gitwarren": {
"command": "npx",
"args": [
"-y",
"gitwarren"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 24 Sept 26 +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.
- 22 Sept 26 +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.
- 20 Sept 26 +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.
- 18 Sept 26 +12
- Stability: 0.07 → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Known CVEs: unverified → pass ▲ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Dependency health: unverified → 1.00 ▲ functional
- First check of Schema quality: unverified functional
- Package version: 0.1.16 → 0.1.17 functional
- 17 Sept 26 +4
- Known CVEs: pass → unverified ▼ security
- Stability: 0.03 → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Malware scan: unverified → pass ▲ security
- Dependency health: 1.00 → unverified ▼ functional
- Capabilities: pass → unverified ▼ functional
- 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 functional
- 16 Sept 26 +1
- Schema quality: 244 → 276 ▼ functional
- Stability: unverified → 0.03 ▲ functional
- Package version: 0.1.12 → 0.1.14 functional
- Package version: 0.1.12 → 0.1.13 functional
- 15 Sept 26 59
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 24 Sept 2026 · Analysed npm/gitwarren@0.1.17
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | npm |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | klarluft/gitwarren-app |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/klarluft/gitwarren-app/.github/workflows/release.yml@refs/tags/v0.1.17 |
| Rekor log index | 2884798826 |
| Predicate type | https://slsa.dev/provenance/v1 |
| Subject digest | sha512:9f710ec3181ca8d9d9927810ea44811d3951f9c7c4a814f178a10ea61d9888332c04f2f571b98dd1297d829eeb6ed8974db887d0cf6296e2a80bd968f |
Background: How many MCP packages publish verified provenance →
Dependencies 2 packages
| Packages resolved | 2 |
|---|---|
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_repository Add repository ~93
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.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | – | – |
| path | string | yes | – |
No output schema declared.
No examples provided.
add_review_comment Add review comment ~813
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:  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:  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…
| Name | Type | Req | Description |
|---|---|---|---|
| agentLabel | string | – | – |
| body | string | yes | – |
| changes | string | – | – |
| filePath | string | – | – |
| line | integer | – | – |
| reviewId | integer | yes | – |
| side | string | – | – |
| startLine | integer | – | – |
No output schema declared.
No examples provided.
agent_identity Agent identity ~105
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.
| Name | Type | Req | Description |
|---|---|---|---|
| label | string | – | – |
No output schema declared.
No examples provided.
create_review Create review ~488
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.
| Name | Type | Req | Description |
|---|---|---|---|
| baseRef | string | yes | – |
| description | string | – | – |
| headRef | string | yes | – |
| repositoryId | integer | yes | – |
| title | string | – | – |
No output schema declared.
No examples provided.
delete_review_comment Delete a comment ~52
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | – |
No output schema declared.
No examples provided.
get_repository Get repository ~28
Fetch one tracked repository by id, with its live git state.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | – |
No output schema declared.
No examples provided.
get_review Get review ~325
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | – |
No output schema declared.
No examples provided.
list_repositories List repositories ~57
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_review_comments List review comments ~579
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…
| Name | Type | Req | Description |
|---|---|---|---|
| reviewId | integer | yes | – |
No output schema declared.
No examples provided.
list_reviews List reviews ~367
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.
| Name | Type | Req | Description |
|---|---|---|---|
| repositoryId | integer | – | – |
| status | string | – | – |
No output schema declared.
No examples provided.
remove_repository Remove repository ~38
Stop tracking a repository. This only removes it from GitWarren - the working copy on disk is never touched.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | – |
No output schema declared.
No examples provided.
remove_review Remove review ~57
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | – |
No output schema declared.
No examples provided.
reply_to_review_comment Reply to a review comment ~569
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:  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:  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…
| Name | Type | Req | Description |
|---|---|---|---|
| agentLabel | string | – | – |
| body | string | yes | – |
| threadId | integer | yes | – |
No output schema declared.
No examples provided.
resolve_review_comment Resolve or reopen a thread ~350
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.
| Name | Type | Req | Description |
|---|---|---|---|
| resolved | boolean | yes | – |
| threadId | integer | yes | – |
No output schema declared.
No examples provided.
update_repository Update repository ~70
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | – |
| name | string | – | – |
| path | string | – | – |
No output schema declared.
No examples provided.
update_review Update review ~376
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.
| Name | Type | Req | Description |
|---|---|---|---|
| baseRef | string | – | – |
| description | string | – | – |
| headRef | string | – | – |
| id | integer | yes | – |
| status | string | – | – |
| title | string | – | – |
No output schema declared.
No examples provided.
update_review_comment Edit a comment ~335
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.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | – |
| id | integer | yes | – |
No output schema declared.
No examples provided.
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.