Donnez à votre agent IA l'édition de documents – en moins de 60 secondes

AgentDoc est un serveur Model Context Protocol (MCP) public. Tout agent LLM qui parle MCP – Gemini, Claude, GPT ou le vôtre – peut se connecter, s'authentifier et utiliser une API d'édition de documents typée complète : lire, écrire, mettre en forme, naviguer, exporter des PDF. Aucun SDK à intégrer, aucun schéma à maintenir de votre côté, aucun humain dans la boucle.

Cette page est le parcours d'intégration canonique pour les agents et les personnes qui les exécutent. Si vous (ou votre modèle) souhaitez disposer d'un éditeur de documents fonctionnel sous forme d'outil, voici tout ce dont vous avez besoin.

Démarrage rapide (un seul appel HTTP)

Enregistrez un compte d'agent isolé et recevez sa clé API en une seule requête. Aucun navigateur, aucun e-mail, aucun humain dans la boucle. Chaque agent enregistré est son propre utilisateur avec sa propre portée documentaire – les différents agents ne voient jamais les documents les uns des autres.

curl -X POST https://agent-doc-edit.com/api/agents/register \
  -H "Content-Type: application/json" \
  -d '{"name": "my-research-agent"}'

# Response
# {
#   "user_id":        "...",
#   "username":       "agent_AbCdEfGh",
#   "name":           "my-research-agent",
#   "api_key":        "ak_...",          <-- shown ONLY here, store it
#   "api_key_prefix": "ak_AbCdEfGh",
#   "created_at":     "2026-04-25T..."
# }

C'est tout. Utilisez la api_key comme jeton bearer auprès de /mcp/sse et l'agent dispose de 35 outils typés pour lire, écrire, mettre en forme, paginer et exporter des documents – entièrement limités à son propre compte.

Deux façons de s'authentifier

Option A – L'agent s'enregistre lui-même (recommandé pour les workflows autonomes)

Utilisez POST /api/agents/register comme indiqué ci-dessus. L'agent obtient son propre compte utilisateur et son propre espace de noms documentaire. Les différents agents n'entrent jamais en collision. Limite de débit : 5 enregistrements par heure et par IP. C'est le bon parcours pour les pipelines de lettres, les traitements par lots, les tâches planifiées, les workflows multi-agents.

Option B – Utilisez votre propre compte humain (pour « donner l'édition de documents à mon propre assistant »)

Ouvrez /app, connectez-vous, barre latérale → « API Keys for Agents » → « + Create New Key ». La clé est affichée une seule fois. Utilisez-la comme jeton bearer. L'agent partage votre compte, vos documents et l'état de votre document actif. Utile lorsque vous voulez qu'un agent copilote opère à vos côtés sur un même corpus.

Ce qui est facturé (et ce qui ne l'est pas)

Les agents apportent leur propre LLM. Vous payez votre fournisseur de modèle pour les jetons de raisonnement. Nous ne les voyons pas, ne les facturons pas, ne les limitons pas. Notre service héberge le serveur MCP, le stockage des documents et le pipeline de rendu. La colonne token_limit sur les comptes d'agent est fixée à 0 comme ceinture de sécurité défensive : si un futur chemin de code tentait un jour d'exécuter notre agent Gemini interne sur une authentification de compte d'agent, il refuserait – les agents restent strictement sur le chemin des outils MCP.

Important : ceci est autonome, pas collaboratif

Ce parcours est conçu pour les workflows d'agents autonomes – votre agent raisonne avec son propre LLM, appelle directement nos outils MCP, édite des documents sur son propre compte et exporte un résultat. La même surface d'outils éprouvée que nos agents vocaux et textuels utilisent en production alimente votre agent – mais votre agent ne parle jamais au nôtre. Il n'y a pas de saut IA-à-IA, pas d'appel LLM interne en votre nom, pas de session partagée avec notre éditeur intégré au navigateur.

Si vous souhaitez qu'un humain et notre agent vocal/textuel coéditent en direct, utilisez directement /app – c'est un parcours différent. Si vous voulez que votre propre agent pilote l'éditeur sans humain, le point de terminaison MCP décrit ici est la bonne surface.

Se connecter depuis n'importe quel client MCP

Python (client mcp / Anthropic / Google ADK)

from mcp.client.sse import sse_client
from mcp import ClientSession
import json

AGENTDOC_TOKEN = "ak_..."  # from POST /api/agents/register

async def edit_document():
    headers = {"Authorization": f"Bearer {AGENTDOC_TOKEN}"}
    async with sse_client("https://agent-doc-edit.com/mcp/sse",
                          headers=headers) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            # Workflow T (~35 tools) is applied automatically. Token is
            # injected from the Authorization header – do NOT pass `token`
            # in tool arguments.
            tools = await session.list_tools()

            # Create a document
            res = await session.call_tool("create_document",
                                          {"title": "My Report"})
            payload = json.loads(res.content[0].text)
            doc_id = payload["doc_id"]   # structured field, no regex

            # Insert content
            await session.call_tool("insert_string", {
                "doc_id": doc_id,
                "text":   "# Hello\n\nFirst paragraph.",
                "index":  0,
            })

            # Trigger PDF; response includes a self-describing fetch URL
            res = await session.call_tool("trigger_pdf_download",
                                          {"doc_id": doc_id})
            pdf_meta = json.loads(res.content[0].text)
            print(pdf_meta["pdf_url"])  # → "/api/doc//pdf"

TypeScript (SDK Anthropic)

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { SSEClientTransport } from "@modelcontextprotocol/sdk/client/sse.js";

const transport = new SSEClientTransport(
  new URL("https://agent-doc-edit.com/mcp/sse"),
  { requestInit: { headers: { Authorization: `Bearer ${TOKEN}` } } }
);
const client = new Client({ name: "my-agent", version: "1.0" }, { capabilities: {} });
await client.connect(transport);

const tools = await client.listTools();
const result = await client.callTool({
  name: "insert_string",
  arguments: { text: "Hello from my agent.", index: 0 }
});

curl (exploration brute)

curl -N -H "Authorization: Bearer $TOKEN" \
     -H "Accept: text/event-stream" \
     https://agent-doc-edit.com/mcp/sse

Catalogue d'outils – le Workflow T est appliqué automatiquement

Les agents externes (c.-à-d. les requêtes authentifiées avec une clé API ak_*) sont automatiquement restreints à la surface d'outils Workflow T – le défaut de production optimal au sens de Pareto que nos propres agents vocaux et textuels utilisent. Vous n'appliquez pas ce filtre ; le serveur MCP l'applique côté serveur à la fois sur tools/list et tools/call. Cela vous donne le sous-ensemble organisé d'environ 35 outils (primitives typées + macros + retour d'observation sur les décalages d'index), supprime le bloc-notes et les outils d'intention FSM qui n'ont pas leur place dans T, et exclut les variantes atomiques « éclatées » utilisées uniquement par notre benchmark de surcharge d'outils. Chaque outil possède un schéma JSON pour ses arguments et renvoie une réponse structurée avec des marqueurs explicites de succès/erreur ; les opérations qui décalent les index incluent un retour d'observation ("observation": "INDEX SHIFT – re-read before next mutation") afin que l'agent reste ancré d'un tour à l'autre.

Initialiser un document à partir d'un DOCX existant

La surface d'outils MCP permet à votre agent de construire des documents à partir de zéro. Pour les workflows qui partent d'un fichier Word pré-rédigé – modèles à en-tête d'entreprise, texte standard de contrat, brouillon entrant à réviser – un point de terminaison HTTP supplémentaire en un seul appel accepte les téléversements de fichiers .docx, crée un nouveau Document sur le compte de l'agent et le bascule en actif afin que le prochain appel MCP atterrisse sur le contenu importé :

# Upload a .docx; response is the new {id, title, ...}
curl -X POST https://agent-doc-edit.com/api/docs/import/docx \
  -H "Authorization: Bearer $API_KEY" \
  -F "[email protected]" \
  -F "title=Q3 Customer Letter"

Les sauts de page, les hyperliens, les en-têtes / pieds de page, les polices, les couleurs et l'interligne survivent tous à l'import. Compte-rendu technique complet : Import DOCX – Aller-retour des documents Word.

Cas d'usage que votre agent peut prendre en charge de manière autonome

• Pipeline de génération de lettres. L'agent reçoit un événement structuré (« présenter des excuses au client X pour le retard Y »), rédige la lettre, la met en forme, exporte un PDF et l'attache à un e-mail sortant.
• Générateur de rapports. L'agent ingère un CSV, synthétise les conclusions, structure le rapport en titres, insère une table des matières, met en forme les chiffres clés en couleur, exporte.
• Refonte de documents. L'agent lit un brouillon existant, réorganise les paragraphes, applique une hiérarchie de titres cohérente, corrige la terminologie incohérente en un seul balayage macro_replace_all, exporte.
• Workflows multi-agents. Un agent de planification décide quoi écrire ; un agent rédacteur appelle les outils AgentDoc pour produire l'artefact ; un agent de vérification lit le résultat et déclenche des révisions.
• Transfert vocal. Un agent vocal reçoit les instructions orales de l'utilisateur et transmet des descriptions de tâches structurées à un agent textuel qui effectue les opérations documentaires réelles sur le même serveur MCP.
• Remplissage de modèles. L'agent téléverse un .docx à en-tête d'entreprise via /api/docs/import/docx, remplit les champs réservés à l'aide de macro_replace_text, exporte le résultat – le collaborateur de l'utilisateur ouvre un fichier Word dans le même Word qu'il a utilisé au départ.

Ce qui rend ceci adapté aux agents (précisément)

• Des outils typés, pas des invites en texte libre. Chaque opération est un outil validé par schéma JSON. L'agent ne peut pas « presque » appeler un outil – les arguments sont analysés ou ils ne le sont pas.
• Retours d'outils structurés. create_document renvoie {"status":"success","doc_id":N,"title":...} – aucune regex sur de la prose. trigger_pdf_download renvoie un {"pdf_url":"/api/doc/N/pdf","method":"GET"} auto-descriptif, si bien qu'un unique GET HTTP de suivi récupère les octets.
• Auto-injection du jeton. Le jeton bearer de votre en-tête Authorization est injecté automatiquement dans chaque appel d'outil – vos arguments d'outil restent exempts d'authentification. (L'agent vocal/textuel interne utilise une convention plus ancienne avec des arguments token explicites ; ce chemin reste pris en charge pour la rétrocompatibilité.)
• Mise en forme déportée. L'agent n'écrit jamais de HTML brut. La mise en forme est un appel typé (format_text(..., format_type="color", format_value="blue")) – la surface la plus facile à halluciner est supprimée.
• Identifiants de document entiers. Des entiers auto-incrémentés, pas des UUID – cela élimine les hallucinations de perte de caractères lorsque l'agent transmet un ID entre les appels d'outils.
• Retour d'observation à chaque mutation. Les retours incluent des observations explicites lorsque les index se décalent, de sorte que l'agent n'a pas besoin de maintenir un modèle mental des décalages cumulés.
• Miroir visuel en temps réel. Le même document que l'agent édite est rendu en direct sur /app. Utile pour la vérification humaine, les démonstrations et les transferts multimodaux.
• Symétrie voix-et-texte. L'agent vocal et l'agent textuel voient exactement la même surface d'outils. Si votre agent fonctionne comme client textuel, il fonctionne aussi comme client vocal.

Limites et contraintes en toute honnêteté

• La facturation du LLM vous incombe. Les agents apportent leur propre modèle. Vous payez votre fournisseur pour les jetons de raisonnement. Notre service héberge le serveur MCP et le stockage des documents ; nous ne facturons pas l'usage du LLM et ne le voyons pas.
• Limite de débit d'enregistrement. 5 auto-enregistrements d'agent par heure et par IP. Conçu pour un provisionnement légitime, pas pour l'abus en masse.
• Débit des appels d'outils. Limite souple par compte sur la couche proxy. Pas de limitation agressive aujourd'hui, mais des boucles non bornées finiront par atteindre les plafonds au niveau nginx.
• Taille des documents. Le point optimal pratique se situe entre 1 et 50 pages (A4). Les très grands documents (200+ pages) fonctionnent, mais le raisonnement de l'agent ralentit car l'outil de lecture renvoie l'état complet.
• Isolation des comptes. Chaque agent enregistré est son propre utilisateur. Les documents sont limités à cet utilisateur uniquement – les agents ne lisent ni n'écrivent jamais entre comptes. Pour partager des documents entre agents intentionnellement, partagez la clé API (Option B ci-dessus).
• Disponibilité du service. Il s'agit d'un service public de niveau recherche, pas d'un SLA de production. Nous visons une haute disponibilité mais n'offrons aucune garantie formelle.

Métadonnées de découvrabilité

• llms.txt – un plan de site en texte brut pour les robots d'indexation LLM sur /llms.txt.
• OpenGraph / JSON-LD – chaque page expose un schéma WebAPI / TechArticle / FAQPage lorsque c'est pertinent.
• URL stables – /agents est canonique et ne bougera pas.

Essayez-le maintenant

Ouvrez l'éditeur dans un onglet, exécutez votre agent dans un autre. Les modifications de l'agent apparaissent en temps réel sur le même écran – utile pour le débogage, les démonstrations ou pour faire collaborer un humain et un agent.

Comptes-rendus techniques

• Granularité des outils dans les agents LLM – principes de conception de la surface d'outils MCP que votre agent appellera.
• Reconstruire l'export PDF + DOCX – comment les points de terminaison d'export reproduisent fidèlement la mise en page à l'écran lorsqu'un agent déclenche un téléchargement.
• Notes de version d'avril 2026 – corrections récentes de la sémantique du moteur de rendu / des décorations / des bascules sur lesquelles s'appuient les agents.