Skip to main content
Glama
README.md
# article-review-mcp

A visual MCP App for reviewing **explicit article patches with categorized comments**.

The editing agent does not hand the server a silently rewritten manuscript. It submits:

```text
unchanged base document
+ explicit patches against that base
+ one or more categorized rationale comments per patch
```

The server validates and applies those patches deterministically, opens an interactive review UI, records human decisions, and safely assembles the final article.

## Why patch-first

A full-document diff can show *what* changed, but it loses the agent's original intent. In this project, a patch is the atomic review object:

```text
Patch
├── exact target in the original document
├── replace / delete / insert_before / insert_after
├── proposed text
├── categorized comments explaining why
└── human decision: pending / accepted / rejected / edited
```

Every comment has exactly one primary `topicId`. A patch may contain multiple comments across different topics.

## Current capabilities

- Explicit `PatchSet` submission against an immutable base document
- `replace`, `delete`, `insert_before`, and `insert_after`
- Base SHA-256 verification
- Exact-anchor resolution with optional `contextBefore` and `contextAfter`
- Rejection of ambiguous anchors and overlapping patches
- Required categorized rationale comments for every patch
- Custom topic taxonomies per review session
- Topic tabs with per-topic patch/comment counts
- Two topic review modes:
  - keep all patches visible and dim unrelated patches
  - show only patches containing the selected topic
- Split, unified, and complete Final views
- Word-level insertion/deletion highlighting for English and Chinese
- Accept, reject, reset, manually edit, and bulk-decide visible patches
- Add, reply to, resolve, and filter reviewer comments
- Compact topic-filtered feedback for the editing agent
- Immutable revision rounds with exact-patch decision carry-over
- JSON persistence, optimistic concurrency, and idempotency
- MCP App plus token-protected localhost browser viewer
- Safe preview, write-new-file, guarded overwrite, and static HTML export
- Legacy `base + full proposal` tools retained as deprecated compatibility aliases

## Requirements

- Node.js 20 or newer
- No runtime dependency installation is required

## Validate

```bash
npm run check
```

The suite runs syntax checks and 13 tests, including a real stdio MCP exchange and localhost viewer calls.

## Run as an MCP server

```bash
node src/cli.mjs \
  --stdio \
  --workspace /absolute/path/to/your/writing-workspace
```

Example client configuration:

```json
{
  "mcpServers": {
    "article-review": {
      "command": "node",
      "args": [
        "/absolute/path/to/article-review-mcp/src/cli.mjs",
        "--stdio",
        "--workspace",
        "/absolute/path/to/your/writing-workspace"
      ]
    }
  }
}
```

## Primary agent call

Call `article_review_submit_patchset`:

```json
{
  "title": "Introduction revision",
  "format": "markdown",
  "base": {
    "type": "workspace_file",
    "path": "manuscript.md"
  },
  "baseHash": "optional-sha256-of-the-base",
  "topics": [
    {
      "id": "architecture",
      "label": "架构与叙事",
      "description": "章节组织、研究主线和段落衔接"
    },
    {
      "id": "logic",
      "label": "逻辑与论证"
    },
    {
      "id": "clarity",
      "label": "表达与清晰度"
    }
  ],
  "patchSet": {
    "id": "revision-001",
    "summary": "补齐 Section 1 到 Section 2 的理论过渡",
    "patches": [
      {
        "id": "selection-pressure-bridge",
        "operation": "replace",
        "target": {
          "oldText": "The later experiments therefore held the candidate text fixed...",
          "contextBefore": "These results support Prediction 1...",
          "contextAfter": "LLM judge reliability varies..."
        },
        "newText": "Collectively, Section 1 establishes that...",
        "comments": [
          {
            "topicId": "architecture",
            "kind": "proposal_rationale",
            "title": "补齐 Section 1 → Section 2 的逻辑桥梁",
            "body": "原文从多智能体失败直接跳到 Judge reliability,缺少为什么需要 Judge 的理论过渡。",
            "severity": "major"
          },
          {
            "topicId": "logic",
            "kind": "proposal_rationale",
            "title": "明确研究问题递进关系",
            "body": "先证明系统存在选择失败,再验证 Judge 是否能够提供可靠信号。"
          }
        ]
      }
    ]
  }
}
```

### Patch rules

- All patches target the same unchanged base document.
- Every patch must include at least one categorized comment.
- Every comment has one and only one primary `topicId`.
- `target.oldText` must resolve to exactly one location.
- Use `contextBefore` and `contextAfter` when the same text appears repeatedly.
- Overlapping patches and multiple insertions at an unsafe shared boundary are rejected.
- The server derives the proposal; the agent does not submit a second complete manuscript in the primary workflow.

Typical validation errors:

```text
BASE_HASH_MISMATCH
ANCHOR_NOT_FOUND
ANCHOR_AMBIGUOUS
PATCH_OVERLAP
MISSING_PATCH_COMMENT
UNKNOWN_COMMENT_TOPIC
```

## Topic-focused review

The UI shows topic tabs such as:

```text
全部主题 12
架构与叙事 4
逻辑与论证 3
证据与引用 2
方法与统计 1
表达与清晰度 2
```

Selecting one topic filters the right-side comments to that topic. The manuscript pane can either:

- retain all patches and dim unrelated ones, or
- hide unrelated patches completely.

`J` and `K` navigate only the patches relevant to the active topic.

## Local viewer fallback

For clients that do not render MCP Apps:

```bash
node src/cli.mjs \
  --viewer 4173 \
  --workspace /absolute/path/to/your/writing-workspace
```

The viewer binds to `127.0.0.1` and prints a random token-protected URL.

Synthetic demo:

```bash
npm run demo
```

## Main tools

Model-facing workflow:

```text
article_review_submit_patchset
article_review_open
article_review_get_feedback
article_review_add_comments
article_review_update_patchset
article_review_finalize
```

App-only review operations:

```text
article_review_get_page
article_review_get_document
article_review_set_patch_decision
article_review_bulk_decide
article_review_edit_patch
article_review_add_comment
article_review_reply_comment
article_review_resolve_comment
```

Deprecated compatibility aliases:

```text
article_review_create
article_review_get_summary
article_review_update_proposal
article_review_set_decision
article_review_edit_hunk
```

## Safety invariants

- The base document is reconstructed byte-for-byte from raw segments.
- Applying every patch reconstructs the derived proposal byte-for-byte.
- CRLF, whitespace, Markdown, Chinese, English, and basic LaTeX are not normalized.
- Manuscript text is rendered as inert text nodes, never through `innerHTML`.
- Absolute paths, `..` traversal, and directory symlink escape are rejected.
- Mutations require `expectedVersion` and `idempotencyKey`.
- Source overwrite requires explicit confirmation, source SHA-256 validation, and a backup.

## Documentation

- [Usage and workflow](docs/USAGE.md)
- [PatchSet protocol](docs/PATCHSET_SCHEMA.md)
- [Editing-agent prompt](docs/AGENT_PROMPT.md)
- [Implemented architecture](IMPLEMENTATION.md)

## Deferred scope

- DOCX Track Changes
- PDF editing
- Word-level partial acceptance
- Real-time multi-user collaboration
- Google Docs synchronization

TDQS

C2.6/5.0

Scored across 19 tools

Disambiguation2/5

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.

Naming Consistency3/5

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).

Tool Count4/5

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.

Completeness4/5

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.