Academic Writer MCP

Historique des révisions

inspect_revision_history

Read-onlyIdempotent

Review an Office document’s revision history to see editing sessions, revision numbers, tracked changes, authors, dates, and retained comments.

Instructions

Sessions d'édition, durée d'édition, numéro de révision, modifications suivies (auteurs, dates) et commentaires conservés dans un fichier Office.

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": {
      "document_id": "<document_id>"
    },
    "name": "inspect_revision_history"
  }
}

Input Schema

Name	Required	Description	Default
`document_id`	Yes

Output Schema

Name	Required	Default
`notice`	No	Historique conservé par le fichier lui-même ; il peut être incomplet ou effacé.
`comments`	Yes
`document_id`	Yes
`revision_number`	Yes
`tracked_changes`	Yes
`editing_sessions`	Yes
`editing_time_minutes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

C2.9/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds useful behavioral context by specifying that the tool reports editing sessions/durations, tracked changes with authors and dates, and retained comments. However, it does not discuss permissions, file-format constraints, or depth/limits of the revision data.

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

Conciseness3/5

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

The description is brief and contains no wasted words, but it is a comma-separated noun phrase rather than a complete front-loaded sentence. It could be clearer if it started with an action like 'Inspecte l'historique des révisions...' before listing the data categories.

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 the description need not explain return values in detail. For a simple read-only inspection tool with one parameter, it covers the data categories well but omits parameter meaning and usage context, leaving meaningful gaps for invocation.

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?

There is one required parameter, document_id, with 0% schema description coverage. The description does not explain whether this expects a file ID, path, or Office document identifier, nor does it clarify any format constraints. The phrase 'dans un fichier Office' implies the target is an Office file but adds little operational meaning for the parameter.

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

Purpose4/5

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

The name and title establish the resource (revision history), and the description enumerates what is surfaced: editing sessions, editing duration, revision number, tracked changes with authors/dates, and stored comments. It is clear enough for an agent to know what data the tool inspects, though it is phrased as a noun list rather than an explicit verb+resource statement.

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?

The description provides no guidance on when to use this tool versus siblings such as get_section_revision, review_revision, or inspect_document_provenance. There are no prerequisites, exclusions, or alternative-selection cues.

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

Deploy Server