Academic Writer MCP

Gabarits de mise en forme

list_format_presets

Read-onlyIdempotent

Lists academic document formatting presets—GOST, APA 7, IEEE, and francophone university—showing fonts, spacing, margins, title-page fields, and Word/PDF export options.

Instructions

Gabarits disponibles (ГОСТ 7.32-2017 14 / 12 pt, usage universitaire francophone, APA 7, IEEE) avec police, interligne, marges, retraits, légendes ; gabarit par défaut du projet ; champs de page de titre ; disponibilité de Microsoft Word (export PDF).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_format_presets"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	No

Output Schema

Name	Required	Description	Default
`presets`	Yes
`word_available`	Yes
`title_page_fields`	No
`default_for_project`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful content detail (what fields each preset reports, default-template exposure, Word/PDF availability) but says nothing about whether the list is scoped by project, whether it is paginated, or what happens with no presets — modest added context beyond structured 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 leading 'Gabarits disponibles' is properly front-loaded, but the rest is one semicolon-chained run-on that mixes preset names, formatting attributes, default-template logic, title-page fields, and export capability. Every element is relevant, yet the flat list makes it harder to scan than separated clauses would.

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 explanation is not required, and the tool is a simple single-parameter lister. However, the one parameter is undocumented in both schema and description, and there is no guidance tying it to the apply_formatting/check_formatting workflow, leaving a real gap for a formatting-pipeline 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 description coverage is 0% for the single optional project_id, so the description must carry the burden and largely does not. The phrase 'gabarit par défaut du projet' vaguely gestures at project scoping, but it never states what project_id does, that it is optional, or what is returned when it is null.

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 opens with 'Gabarits disponibles' and enumerates the concrete catalogue (ГОСТ 7.32-2017, francophone university, APA 7, IEEE) along with the attributes each preset carries (font, spacing, margins, indents, captions). That is a specific verb+resource. It stops short of a 5 because it never distinguishes itself from siblings such as apply_formatting or check_formatting, which an agent could plausibly confuse it with.

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 only implied: an agent can infer this is the read-only step to inspect presets before calling apply_formatting, and the reference to 'gabarit par défaut du projet' hints at project scoping. There is no explicit when-to-use, when-not-to-use, or named alternative, so the routing decision is left to inference.

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

Deploy Server