Academic Writer MCP

Analyser les consignes

analyze_assignment

Extracts assignment requirements from instruction documents, including tasks, length, formatting, deadlines, and required sections, with source references and proposals for user confirmation.

Instructions

Extrait des consignes les exigences : tâches, variante, longueur, normes, échéances, mise en forme, sections imposées, données. Chaque exigence garde sa source (document, page). Ce sont des propositions : les faire confirmer ou rejeter par l'utilisateur.

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": {
      "project_id": "<project_id>"
    },
    "name": "analyze_assignment"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	Yes
`document_id`	No	Document précis ; par défaut tous les documents de rôle « instructions ».

Output Schema

Name	Required	Description
`norms`	Yes
`length`	Yes
`by_kind`	Yes
`variant`	Yes
`warnings`	Yes
`deadlines`	Yes
`extracted`	Yes
`next_step`	Yes
`project_id`	Yes
`missing_data`	No	Données d'entrée nécessaires sans valeur fournie (à demander).
`requirements`	Yes
`suggested_inputs`	No	Données d'entrée attendues par les calculs détectés, avec les valeurs normalisées proposées par défaut (à confirmer par l'utilisateur).
`analyzed_documents`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

B3.4/5.0

Behavior4/5

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

The annotations only supply the generic safety profile (readOnlyHint=false, non-idempotent, non-destructive); the description adds real substance: each requirement retains its source (document, page), and results are provisional proposals subject to user confirmation. This explains why the operation is non-idempotent and non-destructive. It still does not say where proposals are persisted or what happens on re-run, which keeps it below a 5.

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?

Three short sentences, verb-first, with the field enumeration acting as a compact spec. The closing sentence carries the critical caveat about proposals needing confirmation. Slightly dense but nothing is redundant.

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 shape need not be explained, and the description covers source-provenance and the proposal lifecycle. However, it never explains the project scoping parameter, the default document-set behavior, or its relationship to the overlapping extract_requirements sibling, leaving real gaps for a two-parameter analysis tool.

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 coverage is only 50%: document_id is documented in the schema, but project_id has no description anywhere, and the description never mentions either parameter. The important behavioral default, that omitting document_id scans all documents with the 'instructions' role, comes from the schema alone. The description does nothing to compensate for the uncovered 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 description gives a specific verb ('Extrait') and resource ('consignes') and enumerates exactly what is extracted: tasks, variant, length, norms, deadlines, formatting, imposed sections, data. That is far more concrete than the title. It does not distinguish itself from the sibling 'extract_requirements', which is the most likely confusion point, so it falls short of a 5.

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

Usage Guidelines3/5

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

Usage context is implied (this is the first step on an assignment brief) and the closing sentence prescribes a downstream workflow: proposals must be confirmed or rejected by the user. There is no explicit statement of when to pick this tool over 'extract_requirements', and no prerequisites such as whether documents must already be ingested.

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

Deploy Server