Loading ToolBench
MCP server and review monitor for redline: discovers a VS Code window running the redline extension and relays review rounds to Claude Code.
Redline MCP server has well-structured tool definitions with detailed descriptions and complex input schemas. However, several tools lack parameter-level descriptions, and output schemas are not documented. Tool naming is domain-specific but clear. Error handling guidance is minimal. The server targets a specialized use case (code review in VS Code) with tight integration, which explains some design choices, but production-grade tools require more complete parameter documentation and output specifications.
Post notes under an existing round: a remark the user asked for, a follow-up on a file, a pointer to a line. Each note becomes a thread the reviewer sees in the diff as it stands. roundId is the one request_review returned, the one the user gives, or one from list_reviews. Nothing else changes: no diff rebuild, no submit, no new round.
Fetch the reviewer comments for a round as markdown and mark them delivered. Defaults to the newest round with undelivered comments. With wait (seconds, max 120) it blocks until the reviewer submits that round, or without roundId until any round has undelivered comments, then returns them; on timeout it says so and you call it again. Then work through every thread in payload order; each one ends in one of two states. Done: the change landed in the code, or you declined it with the reason. Close it with resolve_comment(threadId, body) and a one-line note. Reviewer's turn: the comment is unclear, you want a yes before changing code, or you answered a question. Post with reply_comment(threadId, body) and leave the thread open. Never author, edit, or delete a human comment. Finish by summarising what changed per thread, then call request_review again on the same source so the round refreshes with your edits; notes are optional there. On a round you have worked before, pass peek: true. It returns one index line per thread plus only the comments you have not seen, no diff context and no history, and marks those threads delivered like a full read. Act from the index when the new comments stand on their own; call get_review({roundId, threads: [id]}) only for a thread that needs its context or history.
List the review rounds of this VS Code window, newest first.
Output schemas not documented. Tools like get_review, list_reviews, and resolve_comment lack documented return types. LLMs cannot plan downstream operations or extract required fields without knowing response structure.
Nested object parameters lack field-level descriptions. The 'source' parameter in request_review is a complex discriminated union with multiple branches (worktree, range, patch, files), but individual fields like 'scope', 'from', 'to', 'text', 'pairs' lack descriptions explaining their purpose and constraints.
Minimal error handling guidance. Tool descriptions do not explain failure modes, recovery steps, or what the LLM should do if a call fails (e.g., 'roundId not found, call list_reviews() to find valid IDs').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Find the VS Code window for this directory and ping the redline extension server. The result's monitor field says whether a redline monitor wakes this session on submit: armed, absent, or unknown.
Post to one thread and hand the turn to the reviewer: a clarifying question, a proposal waiting for a yes, an answer to their question. Markdown, one to three sentences. The thread stays open until they resolve it or reply.
Open a diff as a review round in VS Code, or refresh the open round on the same worktree scope or range so the reviewer sees the current diff with their threads carried over. With roundId instead of source, refresh that round (a round the reviewer opened with Compare, or one from list_reviews) from its stored source and attach the title and notes to it. Returns at once; invoke the redline-connect skill next. To add notes to a round that is already open, call add_notes.
Close a done thread: the change landed, or you declined it with the reason. One call per thread, after its edit. A thread that is the reviewer's turn takes reply_comment instead. body (markdown, one or two sentences) is the closing note on what changed.
Tool 'redline_ping' has vague naming and purpose. The name does not clearly convey what 'ping' does in this context. Description mentions 'monitor field' and 'armed/absent/unknown' states but does not explain when or why an LLM should call this tool.
No pagination or result-limiting guidance. list_reviews lacks documentation of result count limits, pagination support, or ordering. Large review lists could exhaust context windows.