Loading ToolBench
Inline review comments for markdown specs. Built-in MCP server hands feedback directly to your AI agent.
md-redline has 3 tools with generally strong, domain-specific descriptions that clearly explain workflow intent (opening files for review, asking clarifying questions, posting comments). All three tools have input schemas with types and required fields specified. However, parameter descriptions vary in detail, some are thorough, others are minimal. Output schemas are not explicitly documented in the visible code. The tools are well-named with clear action verbs (mdr_request_review, mdr_ask, mdr_comment) and the descriptions are substantial (160 - 370 chars), guiding LLMs on when to use each tool and what to expect. Error handling is minimal, no recovery guidance or error classification. Security appears sound (no secrets in params), but tool composition/chaining information is sparse.
Ask the user one or more questions anchored to specific text in a file inside an active review session. Each question becomes an inline marker the user sees and can reply to in the md-redline UI. Returns with the reply text as soon as the user has answered every question, or with whatever partial replies exist when they finish the review (Done / Finish review), or empty-handed if the session ends another way. Replies also land in the marker threads on disk, so when this tool returns without reply text you should re-read the file(s) before concluding the user did not answer. Use this when a comment is unclear, or when you hit a planning fork while editing. Prefer asking over guessing when the right answer would meaningfully change your edit. Only one mdr_ask can be pending per session at a time. If this returns "a previous mdr_ask is still pending", post a reply to the prior question via mdr_comment — pass this same `sessionId` plus a `replies:` payload targeting that commentId, which resolves the pending ask in-place without opening a second session — and then retry mdr_ask with your new questions.
Post YOUR OWN comments into markdown files for the user to read. Use this when the user asks YOU to review a doc and leave feedback on it. If instead the user wants to review a doc THEMSELVES and have you address what they write ("I want to review X in mdr", "let me review X", "open X so I can comment"), call mdr_request_review, NOT this tool. The word "review" in those requests describes what the user is about to do, not what you should do. This tool writes your comments into their file, which is the opposite of what they asked for. Returns IMMEDIATELY after posting (never blocks). In the `filePaths` form the returned `sessionId` MUST be passed to mdr_wait afterward to block until the user clicks Done — that is a two-tool flow: mdr_comment (post) → mdr_wait (block). This does NOT apply to the `sessionId` form below, which posts into a session you did not open; mdr_wait rejects user-origin sessions. Skipping mdr_wait leaves a banner on the user's screen until they click Done; you will not see their replies or edits before continuing, and any user feedback will be invisible to you for this turn. The comments appear as inline markers anchored to specific text, which the user can then address. Comments are anchored to exact text in the rendered document (not the raw markdown). For text inside Mermaid diagrams or markdown-formatted spans, the renderer will fall back to label/stripped matching. Include `author` on each comment/reply identifying yourself (e.g. 'Claude', 'Codex', 'Gemini'). This appears in the mdr UI so the user knows which agent left the feedback. To reply inside a review the user already has open — the session from an mdr_request_review handoff, or one this tool returned earlier — pass `sessionId` instead of `filePaths`. The batch lands in that session and no second tab or banner appears. Use it whenever you are replying as you work rather than posting a fresh review; the filePaths form always opens its own session.
Output schemas not documented. LLMs cannot infer what fields mdr_request_review, mdr_ask, mdr_comment return, forcing context window waste and downstream tool chaining failures.
Parameter descriptions lack detail. 'filePaths' is described only as 'Absolute paths to markdown files to review (for new sessions)', no constraint on format, count limits, or error handling. 'anchor' in mdr_ask has no guidance on exact-match semantics or fallback behavior.
No error handling or recovery guidance. If mdr_request_review fails (file not found, permission denied, session lost), the tool provides no actionable next steps for the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Open markdown files in mdr (md-redline) so the USER can review them and leave comments for you to address, or continue an existing review session. Use this whenever the user wants to read, review, or comment on a doc themselves, including phrasings like "I want to review X in mdr", "open X so I can comment", or "let me look at X". The user is the reviewer here; you wait and then address what they write. To start a new review, pass filePaths. If you are about to edit or create files the user will review, call mdr_baseline before touching them so the user can see a diff of your changes. Calling it after you have edited does not help: the copy would already include your edits. To continue after addressing a batch of comments, or to re-poll while the user is still reviewing, pass the sessionId from the previous result (without filePaths). If the result says the user has not finished yet, call again with the same sessionId to keep waiting. IMPORTANT: while this tool is waiting (no "batch" or "done" result has arrived yet, or you are between batches), you do not have permission to read, open, edit, or otherwise act on the files under review using other tools. The user is actively writing @comment markers into those files; reading them yourself will surface unsubmitted markers you must not address. Once a "batch" or "done" result arrives you may read/edit the files, but only to address the comments listed in that result — ignore any other @comment markers you encounter in the file.
Tool composition chains poorly documented. mdr_request_review returns a sessionId that must be passed to mdr_ask or mdr_comment, but the response schema is invisible. LLMs cannot see what sessionId looks like or what other fields accompany it.
mdr_ask 'replies' return behavior is vague. Description says replies arrive 'when the user has answered every question' or 'with whatever partial replies exist when they finish the review'. No schema defines what a partial reply looks like or how to distinguish answered vs. unanswered questions.