Academic Writer MCP

Exporter le document

export_document

Builds final DOCX or PDF+DOCX documents from accepted plan sections, applying template formatting, numbered headings, TOC, styled citations, and a bibliography.

Instructions

Produit le document final (DOCX, ou PDF + DOCX via Microsoft Word) à partir des sections ACCEPTÉES du plan : mise en forme du gabarit, titres numérotés, sommaire, citations [@clé] rendues dans le style (gost, apa, ieee, chicago, vancouver), bibliographie. title_page : organization, ministry, faculty, department, document_kind, discipline, title, variant, author, group, supervisor, supervisor_title, city, year — UNIQUEMENT des informations données par l'utilisateur (mémorisées pour la suite ; champs manquants laissés en blanc). include_drafts=true reprend les brouillons non validés (signalés).

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": "export_document"
  }
}

Input Schema

Name	Required	Default
`preset`	No
`project_id`	Yes
`title_page`	No
`output_format`	No	docx
`citation_style`	No
`include_drafts`	No

Output Schema

Name	Required	Description	Default
`ready`	Yes	Aucune section manquante, aucun [À COMPLÉTER], aucune clé inconnue.
`notice`	No		Document produit à partir des seuls contenus validés et des informations fournies ; relire la mise en page finale dans Word (figures à insérer, sauts de page, exigences de la кафедра).
`preset`	Yes
`tables`	Yes
`messages`	Yes
`pdf_path`	Yes
`docx_path`	Yes
`project_id`	Yes
`citation_style`	Yes
`draft_sections`	Yes	Sections reprises d'un brouillon non validé.
`word_finalized`	Yes
`sections_included`	Yes
`citations_rendered`	Yes
`unwritten_sections`	Yes
`bibliography_entries`	Yes
`unknown_citation_keys`	Yes
`placeholders_remaining`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare this is not read-only, not idempotent and not destructive, so the safety profile is partly covered. The description adds real behavioral context beyond that: PDF output depends on Microsoft Word, drafts are included only on request and are flagged, and title_page values are 'mémorisées pour la suite' with missing fields left blank — a disclosure of persisted state. It does not cover overwrite behavior, whether re-exporting replaces an existing file, or why the operation is non-idempotent.

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?

The output artifact and its constraints are front-loaded, then parameter-specific notes follow, which is a sensible ordering. The title_page enumeration is long but each item earns its place as a field hint; the wording is dense but not padded.

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?

For a fairly complex assembly tool it covers the essential mechanics and, with an output schema present, needn't explain return values. Still, the opaque 'preset' parameter and the required project_id have no explanation anywhere, and there is no guidance on prerequisites or failure conditions, so an agent may call it correctly in shape but not always in intent.

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

Parameters3/5

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

Schema description coverage is 0%, so the description carries the full burden. It does well for title_page (complete field list plus the important constraint that only user-supplied information should be used and blanks stay blank) and for include_drafts, and it reveals the accepted values for citation_style (gost, apa, ieee, chicago, vancouver). However, 'preset' is never mentioned and output_format is only obliquely implied by 'DOCX, ou PDF + DOCX', leaving two of six parameters undocumented.

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

Purpose5/5

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

The description opens with a specific verb and artifact: 'Produit le document final (DOCX, ou PDF + DOCX via Microsoft Word)' from the plan's ACCEPTED sections, and enumerates the concrete operations it performs (template formatting, numbered headings, TOC, citation rendering, bibliography). This clearly separates it from sibling export/extract tools such as export_references or extract_document_content.

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 is implied rather than stated: exporting only ACCEPTED sections tells the agent this is the final-assembly step after validation, and include_drafts=true is described as the exception that pulls in non-validated drafts. There is no explicit when-not guidance or routing to alternatives (e.g. quality-check or reference-export siblings) and no stated prerequisites such as needing an existing outline.

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

Deploy Server