Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MDREVIEW_BASENoBase URL of the mdreview service for self-hosted instances, e.g. http://localhost:8137.
MDREVIEW_TOKENNoYour 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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
create_reviewA

Create a review from markdown; returns the id and the review and feedback urls. The viewer renders GFM, Mermaid diagrams (mermaid fenced blocks), LaTeX math ($...$ inline, $$...$$ display), GFM footnotes, syntax-highlighted fenced code (label the language) and images (attach them with attach_asset). A flow, decision tree, state machine or architecture reads best as a mermaid diagram, since a plain code fence renders as monospace text. Optional project, session and source_path record where the draft came from, for the dashboard. kind="latex" (default "markdown") makes a research-paper review instead: markdown then carries raw LaTeX (a single .tex document), shown in a split viewer with a live server-compiled PDF, and the markdown rules do not apply. If the content is LaTeX (a .tex source_path, or a body with \documentclass or \begin{document}), set kind="latex"; a latex-enabled server rejects the create otherwise. kind cannot change later. Recreating a review in the other format makes a new review with a new id and url, and its comments and history do not carry over.

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 round, fetch one past draft plus the feedback it received.

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 content_b64 (base64) and name as the exact src the draft uses (for example "/assets/x.png" or "fig/y.svg"). Attach once; it survives every update_source revision. On the local stdio server you can pass path instead, a local file path the wrapper reads and encodes for you, which keeps large files out of the conversation. A remote server cannot read your files, so it needs content_b64. Returns the stored name and the served url.

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 quoted_text = the exact phrase from the source to anchor to (the viewer highlights it wherever it occurs) and text = your comment. Omit quoted_text for a document-level (unanchored) note. Attributed to role (default agent). After this, the reviewer (or you) can reply/resolve it like any thread.

list_commentsA

List comments on a document, filtered by status: open (default), resolved, reopened or all. Reply to a comment to discuss it; resolve it once it is addressed.

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. justification is OPTIONAL — provide a short note (appended to the thread, attributed to you, the agent) to explain what you did, or omit to resolve silently; a clear note is recommended because the reviewer can REOPEN the thread, so it reduces back-and-forth. On resolve the comment leaves the active document and moves to the Resolved panel. You never reopen — after a reviewer reopens, you'll see the comment again via list_comments (status reopened/open) and can reply or resolve again.

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); message is shown in that banner. Use it after update_source and the replies or resolves on the comments you addressed, or when blocked; for blocked, pair it with a comment reply that asks the question. Reopening a comment is a reviewer action in the viewer, not an agent action. Not available on a kind=latex review, which has no turn baton.

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. owner is YOUR opaque session id; a review already leased by a DIFFERENT owner returns an error (HTTP 409) — back off and skip it (another agent holds it). Does NOT change whose turn it is. Not available on a kind=latex review: there is no turn baton in latex mode.

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 python3 mcp_server.py --print-version on disk; if they differ, the running process is stale and the MCP client should be reconnected to load the new code. An MCP-only agent has no on-disk value to compare with, so it cannot make that check itself.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 21 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivitySlowing
ResponsivenessResponsive