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.

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.

Block until the user has finished engaging with an mdr_comment session. Call this once after you have posted all your feedback batches via mdr_comment. Returns when the user clicks Done in the mdr UI. If the wait times out (90s), returns {status:"pending"} — call mdr_wait again with the same sessionId to keep waiting. After this returns {status:"done"}, read the file(s) to see the user's replies, deletions, and resolutions.

Add markdown files to a review session that is already open in mdr (md-redline), without starting a new one. Use it when the reviewer asks for another file mid-review, or when you need to comment on a file the session does not cover yet. Works for sessions from mdr_request_review and mdr_comment alike. The reviewer's mdr tab opens the new files. Returns immediately; carry on with the same sessionId as before. A session that has ended cannot take more files: start a new review instead.

Call this BEFORE you edit markdown files the user will later review in mdr (md-redline). It saves a copy of each file as it is right now so the reviewer's diff can show exactly what you changed. Returns immediately. Include files you are about to create (their folder must already exist); they are saved as empty. Do not call it after you have already edited a file: the copy would already contain your changes. Workflow: mdr_baseline (before editing) -> edit the files -> mdr_request_review. At most 64 files per call. If the reviewer already has a before point for a file from an earlier handoff or review, that one is kept.