Academic Writer MCP

Rapport d'audit IA

generate_ai_audit_report

Generates a structured Markdown audit report that flags potential AI-writing indicators, observations, confidence limits, and recommendations for human review.

Instructions

Produit le rapport d'audit complet (Markdown) : passage analysé, types d'indices, observations, confiance non calibrée, limites, conclusion, recommandations ; enregistré dans le dossier exports du projet. Indices pour un examen humain, jamais des preuves ; aucune décision ne doit reposer sur ce seul rapport.

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

Input Schema

Name	Required	Description	Default
`document_id`	Yes

Output Schema

Name	Required	Description	Default
`basis`	Yes	Ce sur quoi repose la conclusion.
`style`	Yes
`limits`	Yes
`audit_id`	Yes
`filename`	Yes
`metadata`	Yes
`integrity`	Yes
`conclusion`	Yes
`confidence`	No		non calibrée
`provenance`	Yes
`document_id`	Yes
`report_path`	No
`recommendations`	Yes
`report_markdown`	No
`conclusion_label`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations only declare readOnly=false, destructive=false, idempotent=false, openWorld=false. The description adds real behavioral context beyond them: the output is Markdown, it is persisted to the project's exports folder (a write side effect on disk), and it carries an explicit caveat about uncalibrated confidence and limits. It does not clarify whether repeated calls overwrite or accumulate files, which is exactly the gap left by idempotentHint=false.

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?

Front-loaded with the deliverable and its format, followed by the content list and the caveat. The mid-sentence enumeration is a little dense but every clause carries information; no filler.

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?

Output schema exists, so the enumerated section list is a bonus rather than a necessity, and the disk-persistence side effect plus the interpretation caveat make the definition usable as-is. The main remaining hole is the lack of guidance on ordering relative to the indicator-detection step and on file overwrite behavior.

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% for the single parameter document_id, so the schema name alone must carry the meaning. The description only indirectly implies the input identifies the analyzed passage/document ('passage analysé'), without stating what kind of identifier is expected or whether it must be a project-owned document. Marginal compensation for the coverage gap.

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?

States a specific verb and artifact: it 'produit le rapport d'audit complet (Markdown)' and enumerates the report's contents (passage analysé, types d'indices, observations, confiance non calibrée, limites, conclusion, recommandations). An agent knows exactly what it gets. It does not name a sibling to contrast with (e.g. detect_ai_indicators or final_quality_audit), 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?

Adds an interpretive constraint — the indicators are for human review, never proof, and no decision should rest on this report alone — which is useful guidance on how to treat the output. However, it never says when to invoke this versus the sibling audit/report tools, nor any prerequisite such as having already run the indicator detection step.

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

Deploy Server