Skip to main content
Glama
Sign In
Academic Writer MCP

Academic Writer MCP

by academic-writer-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Importer un document

import_document
Idempotent

Imports DOCX, PDF, TXT, MD, XLSX, and PPTX files into a project as verified read-only copies, rejecting suspicious files and preventing duplicate imports.

Instructions

Importe un fichier (DOCX, PDF, TXT, MD, XLSX, PPTX) dans un projet.

    Le fichier original n'est jamais modifié : une copie vérifiée (SHA-256) est
    stockée en lecture seule. Les fichiers suspects (macros, contenu ne correspondant
    pas à l'extension, archives anormales) sont refusés. Un fichier identique déjà
    importé n'est pas dupliqué.

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>",
      "file_path": "<file_path>"
    },
    "name": "import_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleNoRôle du document : instructions (consignes), source, draft (document de l'utilisateur), data, template, other.source
titleNoTitre lisible facultatif.
file_pathYesChemin absolu du fichier sur l'ordinateur de l'utilisateur (ex. D:\Cours\consignes_TP3.pdf).
project_idYesIdentifiant du projet.

Output Schema

NameRequiredDescriptionDefault
messageYes
documentYes
duplicateYesVrai si un fichier identique (même SHA-256) existait déjà.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

Adds substantive behavior beyond the annotations: the source file is never mutated, a SHA-256-verified copy is stored read-only, suspicious files are refused with named criteria, and identical files are not duplicated. That last point corroborates idempotentHint=true, and the read-only-copy guarantee explains what destructiveHint=false means here. It stops short of stating whether a rejection is an error vs. a no-op result, or any size/rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, no waste, with the core action front-loaded before the behavioral guarantees. Each sentence contributes a distinct fact (formats, immutability, rejection rules, dedup).

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?

With annotations, full schema coverage, and an output schema, the description covers what an agent needs to call it safely, including the failure modes. The remaining gap is workflow context: it does not indicate that import is typically followed by inspection/extraction siblings, nor whether a refused file surfaces as an error.

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 100%, so file_path, project_id, title, and the DocumentRole enum are already documented in the schema. The description adds no meaning about the role parameter or what an absolute path must look like; baseline 3 applies when the schema carries this load.

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 resource ("Importe un fichier … dans un projet") and enumerates the accepted formats (DOCX, PDF, TXT, MD, XLSX, PPTX), which is more than the name conveys. However, it never distinguishes itself from the sibling import_sources_file, so an agent cannot tell which importer applies without opening both schemas.

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?

The intent 'bring a document into a project' is implied, and the rejection rules hint at preconditions (no macros, extension must match content). There is no explicit when-to-use vs. when-not guidance and no pointer to which sibling handles the follow-up step (extraction, metadata, integrity checks).

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