mdreview-service
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MDREVIEW_BASE | No | Base URL of the mdreview service for self-hosted instances, e.g. http://localhost:8137. | |
| MDREVIEW_TOKEN | No | Your mdreview API token for the hosted service (mdreview.space). Omit to be prompted for it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_reviewA | Create a review from markdown; returns the id and the review and feedback urls. The viewer renders GFM, Mermaid diagrams ( |
| list_reviewsA | List every review with its status (awaiting/feedback/resolved), note counts, and revision. |
| get_reviewB | Get one review's metadata. |
| get_sourceA | Get a review's current source — the draft you edit (markdown, or raw LaTeX for a kind=latex review). Read it before applying feedback when you didn't keep the draft in memory (e.g. a resumed session). By default the result is the raw document verbatim, exactly as before. Pass with_revision=true to instead get a JSON envelope {"source": ..., "revision": N}: the revision is the optimistic-concurrency token for update_source's expected_revision, issued atomically with this read (same response), so use THIS — never a separate get_status poll — as the token source when you plan a guarded save. |
| get_feedbackA | Get a review's human feedback: structured notes (now including a projection of the comments) plus the rendered markdown block. For the full threads use list_comments. |
| get_statusA | Cheap poll: a review's source_updated, feedback_updated, and comments_updated timestamps. Watch comments_updated for new/changed comment threads. Also carries revision and can_edit (#288) — but for a guarded update_source take the revision from get_source(with_revision=true), the read that gave you the text, never from this poll. source_updated_by (#289) names who authored the current draft: "reviewer" means the human edited the document since your last write, so re-read the source before saving; "agent" (the default) means the last write was yours. |
| update_sourceA | Push a revised draft (applied edits). Snapshots a history round and live-reloads the human's page. A markdown review is rendered as in create_review (Mermaid, math, highlighted code). For a kind=latex review the draft is raw LaTeX (a single .tex document) and the server recompiles it to PDF on each push. The human can edit the document too, so save with a guard: read via get_source(with_revision=true) and pass that revision as expected_revision. A stale revision fails with HTTP 409 and writes nothing. On a 409, re-read the source, re-apply your change onto the new text and save with the fresh revision; never resend the earlier draft, which would silently overwrite the human's edit. Omitting expected_revision is an unconditional write. |
| get_historyA | List a review's past rounds; with |
| get_git_urlA | Returns a git clone URL for a review's history: one commit per past round plus a live tip commit, so git log, git diff and git blame work with standard tools. Only available when the server has git-tracked history enabled; otherwise the call returns 404. Read-only: no push, no branching. |
| delete_reviewB | Delete a review and its data. |
| attach_assetA | Attach an image to a review so the viewer serves and renders it. Pass the file bytes as |
| list_assetsB | List a review's attached assets (name, stored name, served url, bytes, ctype). |
| create_commentA | Author a NEW comment on a document, anchored to a quoted phrase — use this to leave review feedback at a specific spot (you act as a reviewer). Pass |
| list_commentsA | List comments on a document, filtered by |
| get_commentA | Fetch one comment thread in full — every reply plus the status_history (the open -> resolved -> reopened transitions). |
| reply_to_commentA | Add a reply to a comment WITHOUT resolving it. Use this when a comment is a question or needs discussion, or to respond before you decide — resolve only once the issue is actually addressed. |
| resolve_commentA | Mark a comment resolved once you've actually addressed it. |
| delete_commentA | Permanently deletes a comment and its whole thread. This cannot be undone. Use it to remove a comment created by mistake; resolve_comment marks a real comment addressed and keeps it in the Resolved panel. |
| hand_backA | Hand the turn back to the reviewer. Sets turn=reviewer on the review, so the viewer's banner reads 'Agent updated the draft, your turn' (state=done, the default) or 'Agent needs you' (state=blocked, used when you replied with a question instead of finishing); |
| ping_workingA | Claim or renew your lease on a review while you hold the turn. Find work by polling list_reviews / get_status for reviews you own with turn=='agent'; on one, call ping_working right away and then periodically while you work, so the viewer shows 'Agent is working…' instead of a stale 'Agent may have stopped' hint. |
| server_infoA | Reports this running MCP server's name, version, protocol_version, tools_hash, tool_count and tool_names. It describes only the running process and makes no call to the service. A human or CI compares tools_hash to |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Most tools target clearly distinct resource+action pairs (review, source, comment, asset, turn). The only real friction is the read surface: get_review vs get_status vs get_source vs get_feedback, and get_feedback vs list_comments/get_comment overlap slightly, though the descriptions explicitly steer ('for the full threads use list_comments', 'use get_source(with_revision=true) not this poll'). Those caveats make the boundaries learnable but not frictionless.
The set is dominated by a clean verb_noun snake_case pattern (list_reviews, create_review, get_source, update_source, resolve_comment, delete_comment, attach_asset). Three outliers — hand_back, ping_working, server_info — are idiomatic and self-describing, so they read as minor deviations rather than a broken convention.
21 tools is heavy for a review service; the comment CRUD block (create/list/get/reply/resolve/delete) plus four read variants on one review account for most of the surface. Each tool is well motivated, but coordination extras (hand_back, ping_working, server_info, get_git_url) push it into borderline territory where a few could collapse into options on existing calls.
Coverage is strong: full review lifecycle, optimistic-concurrency source updates, history and git backends, assets, comment threads with resolve/reopen, and turn/lease coordination. Gaps are small — assets can be attached and listed but not removed, review metadata is immutable (kind, project), and reopen is deliberately reviewer-only, all workable around.