Skip to main content
Glama
Sign In
Academic Writer MCP

Academic Writer MCP

by academic-writer-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Rédiger une section

write_academic_section

Drafts or revises a section from an approved academic plan using a chosen AI engine, returning a proposed revision with automated checks or a prompt-brief dossier for manual drafting.

Instructions

Rédige une section du plan approuvé. Avec un moteur serveur (modèle local ou cloud autorisé), renvoie une révision PROPOSÉE avec ses contrôles automatiques. Avec le moteur « assistant », renvoie le dossier (system_prompt + brief) : rédiger alors soi-même puis appeler save_section_draft.

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>",
      "section_id": "<section_id>"
    },
    "name": "write_academic_section"
  }
}

Input Schema

NameRequiredDescriptionDefault
engineNoMoteur ; par défaut celui de la configuration (auto).
project_idYes
section_idYes
instructionsNoPrécisions de l'utilisateur pour cette section.

Output Schema

NameRequiredDescriptionDefault
briefNoDossier à rédiger (moteur assistant).
engineYes
revisionNoRévision proposée (moteur serveur).
next_stepYes
engine_reasonYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true and non-idempotent, and the description adds the crucial point that a server engine yields only a PROPOSED revision with automatic checks, while the assistant engine performs no generation at all and returns a dossier (system_prompt + brief). That dual behavior is real information beyond structured fields, though what the automatic checks verify is unstated.

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 front-loaded sentences with no filler: purpose first, then the two engine behaviors in the order an agent must decide between them. The dense quoting around 'assistant' is the only friction, but nothing is redundant.

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

Completeness4/5

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

Since an output schema exists, return values need not be described, yet the description still explains that the payload differs by engine and that drafting may fall back to the agent plus save_section_draft. What 'contrôles automatiques' consists of is left implicit, which is a minor remaining hole for a generation tool.

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

Parameters4/5

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

The schema only labels 'engine' as a configured engine with default auto; the description supplies the semantics of its values by splitting them into server engines (local model or authorized cloud) versus the 'assistant' mode, which changes the return contract entirely. project_id and section_id remain undocumented in both schema and description, and 'instructions' is left to its schema line, which keeps this below a 5 at 50% coverage.

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 names a specific verb and resource ('Rédige une section du plan approuvé') and scopes it to an approved outline, which separates it from free-form rewriting tools. It also bears on output shape per engine, so an agent can tell what it gets back before opening the schema.

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

Usage Guidelines4/5

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

The description states the workflow branches clearly: with a server engine it returns a proposed revision, and with the 'assistant' engine the agent must draft itself and then call save_section_draft. It sits out explicit exclusions against rewrite_academic_section or correct_academic_section, which is the remaining gap.

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

Deploy Server

Other Tools