Add review comment
add_review_commentPost a comment on a GitWarren review, either as a general note or anchored to a specific line in the diff or file, with options for diff side and line ranges.
Instructions
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 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 Schema
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| line | No | ||
| side | No | head | |
| changes | No | all | |
| filePath | No | ||
| reviewId | Yes | ||
| startLine | No | ||
| agentLabel | No |