ShadowGit MCP Server

Read the review comments

get_review_comments

Read-onlyIdempotent

Read unresolved ShadowGit review comments for a tracked project, grouped by Send with file, line, and quote context, so you can address each comment and reply.

Instructions

Read the review comments the person sent you from ShadowGit for a tracked project: the sent ones they have not resolved, grouped by the Send that carried them, oldest first. Each comment has its id, its tag (change, question or note: the person's own), its words and where it is. That is the snapshot it was written on, the file, the lines, numbered as in that snapshot (side head: its new lines; side base: lines it removed, which the file no longer has; null for the whole file), the lines quoted as they read then, and the definition around them. It also has since, the snapshot that changed its quoted lines after it was written (null when none did), and the replies so far. Each Send has the change the person had open and the files of that change they had not viewed (unviewed, then moreUnviewed), so a file they did not read is not one they approved. Change only what each comment asks, at its lines: a question is answered in your reply, and a note changes nothing unless its words ask for a change. Ask the person before you change anything else. Once a comment is done, reply to it with reply_to_review_comment: what you changed, or your answer. Only the person resolves a comment, in ShadowGit. Needs the ShadowGit app running.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_review_comments"
  }
}

Input Schema

Name	Required	Description	Default
`repo`	No	Project name or absolute path. Defaults to the current project.

Output Schema

Name	Required	Description
`next`	No	The step that follows: change what each comment asks, then reply to each
`repo`	Yes
`sends`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.9.0Nov 5, 2026

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuinely non-structured behavior: it only surfaces unresolved *sent* comments, ordering is oldest first, resolution happens only by the person in ShadowGit (this tool cannot resolve), and the ShadowGit app must be running. Those are real operational facts not available from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and scope are correctly front-loaded in the first sentence. However, the middle of the description enumerates return fields one by one (id, tag, words, where, snapshot, file, lines, side, quoted lines, definition, since, replies) when an output schema already exists, making the text noticeably longer than the tool's single-parameter complexity warrants.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, return-value detail is technically optional, but the description still supplies what an agent needs to act: the unresolved-sent-only filter, ordering and grouping, the app dependency, and the follow-up path via reply_to_review_comment. Nothing essential to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single `repo` parameter is already documented as 'Project name or absolute path. Defaults to the current project.' The description only alludes to 'a tracked project' without adding format or defaulting semantics, so the schema carries the load and the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (read the review comments) plus the exact scope of what is returned: comments 'the person sent you ... the sent ones they have not resolved, grouped by the Send that carried them, oldest first'. This distinguishes it clearly from sibling reply_to_review_comment, which is named separately as the write path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete downstream guidance: 'Change only what each comment asks, at its lines', 'a question is answered in your reply, and a note changes nothing unless its words ask for a change', 'Ask the person before you change anything else', and routes to reply_to_review_comment once a comment is done. It does not name an alternative for retrieving other comment states (e.g., resolved comments), which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server