Academic Writer MCP

Accepter ou refuser une révision

review_revision

Apply an accept or reject decision to a revision: accepting replaces the prior accepted version, preserves it in history, and marks the section as validated.

Instructions

Applique la décision de l'utilisateur. Accepter remplace la version acceptée précédente (conservée dans l'historique) et marque la section comme validée.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "revision_id": "<revision_id>",
      "decision": "<decision>"
    },
    "name": "review_revision"
  }
}

Input Schema

Name	Required	Description
`note`	No
`decision`	Yes	Décision DE L'UTILISATEUR.
`revision_id`	Yes

Output Schema

Name	Required	Description	Default
`id`	Yes
`kind`	Yes
`note`	No
`text`	Yes
`model`	Yes
`checks`	Yes
`engine`	Yes
`status`	Yes
`version`	Yes
`language`	Yes
`created_at`	Yes
`decided_at`	No
`project_id`	Yes
`section_id`	Yes
`word_count`	Yes
`section_title`	Yes
`parent_revision_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

C2.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations only flag it as a non-read-only, non-idempotent, non-destructive mutation, so the description earns credit for disclosing what actually happens: the previous accepted version is replaced but retained in history, and the section is marked validated. The reject branch, however, is left entirely unexplained, leaving half the tool's behavior opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and then the accept-branch consequences. Nothing is redundant, though the space saved could have been spent on the reject path.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. For a mutation tool with two undocumented parameters and an unannotated non-idempotent flag, however, the description should at minimum cover the reject outcome and what a repeat call does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% — only 'decision' carries a (redundant) description, while revision_id and note are undocumented in both schema and description. The description never clarifies what revision_id identifies or what the free-text note is applied to, so it does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it applies the user's decision to a revision, and the accept branch is explained concretely (replaces the previous accepted version, marks the section validated). But the opening verb phrase ('Applique la décision de l'utilisateur') never names the object being acted on, and nothing distinguishes it from siblings like get_section_revision or inspect_revision_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus inspecting or reading a revision, and no prerequisites (e.g. that the user must already have made a decision, or that a revision may need to be fetched first). The schema's 'Décision DE L'UTILISATEUR' hints at a precondition but the description does not develop it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server