article-review-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
| resources | {} |
| experimental | {
"io.modelcontextprotocol/ui": {
"protocolVersion": "2026-01-26"
}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| article_review_submit_patchsetA | Primary article-edit workflow. Submit the unchanged base document plus explicit non-overlapping patches. Every patch must include at least one comment assigned to exactly one primary topic. Use this instead of returning a giant rewritten document or textual diff in chat. |
| article_review_openC | Open an existing visual patch review and optionally filter it by comment topic. |
| article_review_get_feedbackA | Return compact pending or rejected patch feedback for an editing agent. Filter by one comment topic without returning the complete manuscript. |
| article_review_add_commentsC | Attach a batch of reviewer comments to existing patches. Each comment must use exactly one primary topicId. |
| article_review_update_patchsetB | Create an immutable next review round from the same base document. Exact unchanged patches may carry decisions and reviewer comments; changed patches reset to pending. |
| article_review_finalizeA | Preview or safely write the article assembled from accepted, rejected, edited, and pending patches. Overwrite requires confirmation, hash checking, and backup. |
| article_review_get_pageC | Load paginated patches, optionally showing only one comment topic. |
| article_review_get_documentC | Load the complete assembled document for the Final view. |
| article_review_set_patch_decisionC | Accept, reject, or reset one patch. |
| article_review_bulk_decideC | Accept, reject, or reset all or selected patches. |
| article_review_edit_patchC | Save a human-authored replacement for one patch. |
| article_review_add_commentC | Attach one reviewer comment to a patch under exactly one primary topic. |
| article_review_reply_commentC | Record how an editing agent implemented a reviewer comment. |
| article_review_resolve_commentC | Mark a review comment resolved or unresolved. |
| article_review_createA | Compatibility tool for base + complete proposal. Prefer article_review_submit_patchset so every change retains agent intent and categorized comments. |
| article_review_get_summaryA | Compatibility alias for article_review_get_feedback. |
| article_review_update_proposalB | Compatibility tool for complete revised documents. Prefer article_review_update_patchset. |
| article_review_set_decisionD | Compatibility alias for article_review_set_patch_decision. |
| article_review_edit_hunkC | Compatibility alias for article_review_edit_patch. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Article Review App | Interactive topic-filtered article patch review |
TDQS
Scored across 19 tools
Multiple tools have overlapping purposes, including explicit compatibility aliases (create/submit_patchset, get_summary/get_feedback, set_decision/set_patch_decision, edit_hunk/edit_patch) and single/batch variants (add_comment/add_comments). This makes it difficult to tell tools apart despite clear descriptions.
All tools share the article_review_ prefix, but verb/object patterns vary: some omit objects (open, finalize, create), one uses an adverb (bulk_decide), and compatibility aliases introduce inconsistent verbs for the same action (e.g., set_decision vs set_patch_decision).
At 19 tools, the count is slightly above the ideal 3-15 range, but the patch-based review workflow is inherently complex. The presence of 5 redundant compatibility tools inflates the count unnecessarily, keeping it from a perfect score.
The surface covers the full review lifecycle: patch submission, update rounds, decisions, commenting, feedback, pagination, and finalization. Minor gaps exist, such as no explicit patch deletion or comment topic management, but these are workable.