Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GestSup MCP find tickets for user john@example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Serveur MCP (Model Context Protocol) pour piloter les tickets GestSup depuis un agent LLM (Claude Desktop, etc.), accompagné d'un plugin serveur GestSup qui ajoute les endpoints manquants (recherche + écritures) et d'une documentation de l'API REST GestSup.
Élément | Description |
Serveur MCP ( | Outils de gestion de tickets (lecture + écriture) à brancher sur un client MCP. |
Guide de lecture du code : comprendre et savoir expliquer chaque partie (revue/production). | |
Installation pas à pas, partie par partie (GestSup → stockage → MCP → client). | |
Guide de démarrage : brancher GestSup + vault Obsidian (local ou serveur SMB/NFS) sur Hermes/Claude. | |
Plugin GestSup ( | Addon serveur (PHP) : endpoints de recherche et d'écriture, qui répliquent la logique native et réutilisent le mailer natif. |
Documentation de l'API REST GestSup native, reconstruite depuis le code source. | |
Runbook : mettre à jour le plugin/MCP quand GestSup évolue. | |
Harnais de revalidation bout-en-bout (endpoints + mails) contre une instance réelle. | |
Instance GestSup jetable (données d'exemple, plugin auto-installé) pour tester. | |
Swagger d'origine de GestSup (incomplet, fourni pour référence). |
Related MCP server: GLPI MCP
🔌 = nécessite le plugin serveur gestsup_mcp installé et activé.
Outil | Rôle | |
| Lire un ticket + son fil de résolution | natif |
| Lister les tickets d'un demandeur (tri + pagination) | natif |
| Lire la fiche d'un utilisateur | natif |
| Listes de l'instance : type/catégorie/sous-cat/lieu (natif) ; état/priorité/criticité/cause/groupe/technicien/procédure (🔌) | natif + 🔌 |
| Rechercher des tickets (technicien, état, catégorie, mots-clés, dates, exclusion d'états) | 🔌 |
Outil | Rôle | |
| Créer un ticket simple (titre, description, type, email demandeur) | natif |
| Créer un ticket complet (demandeur, catégorie, priorité, type, temps, technicien…) | 🔌 |
| Ajouter un commentaire public (mail au demandeur) ou une note interne (sans mail) | 🔌 |
| Changer l'état (résoudre, rejeter, en cours…) | 🔌 |
| Affecter à un technicien ou un groupe | 🔌 |
| Mettre à jour catégorie / sous-cat / priorité / criticité / type / temps | 🔌 |
| Clôture conforme (cause + procédure obligatoires) | 🔌 |
Toutes les écritures répliquent la logique native de GestSup et réutilisent
son mailer : les notifications partent exactement selon tes paramètres
(mail_auto_*). Aucune valeur de liste n'est codée en dur : les ids (états,
priorités, catégories, techniciens, procédures…) sont lus de ton instance et
validés. L'identité de l'acteur = GESTSUP_DEFAULT_USER_ID.
📓 = activé uniquement si un vault est configuré (OBSIDIAN_VAULT_PATH).
Outil | Rôle | |
| Évaluer si un ticket est riche et propre (score, signaux, manques) avant de le capitaliser | natif |
| Proposer de documenter un ticket en fin de traitement, sauf si un cas similaire couvrant la même résolution existe déjà | 📓 |
| Lister les notes du vault (filtre dossier / nom) | 📓 |
| Chercher dans la doc (titre, tags, corps) — « a-t-on déjà eu ce problème ? » | 📓 |
| Lire une note (frontmatter + corps) | 📓 |
| Créer / remplacer une note (idéal : doc issue d'une conversation) | 📓 |
| Ajouter / remplacer une section | 📓 |
| Générer un article KB depuis un ticket (Problème / Contexte / Résolution / Liens) | 📓 |
L'accès au vault est par fichiers (lecture/écriture directe des .md) :
aucune dépendance à l'app Obsidian ni à un plugin tiers, donc compatible avec
n'importe quel client MCP (Hermes agent, Claude Desktop…). gestsup_document_ticket
avertit si le ticket est jugé pauvre (verdict + manques) mais documente
quand même si demandé — c'est au LLM de décider. Anti path-traversal, écrasement
jamais silencieux (mode explicite), kill-switch OBSIDIAN_ALLOW_WRITES.
Vault sur un serveur de fichiers (SMB/NFS…). Comme l'accès est par fichiers,
il suffit de monter le partage sur la machine du MCP et de pointer
OBSIDIAN_VAULT_PATH sur le dossier monté (aucun client SMB embarqué, donc rien
de fragile). Au démarrage, le serveur vérifie que le vault est joignable et
le signale ; si le partage est démonté, les outils de doc renvoient un message
clair (« vault injoignable — partage monté ? ») sans planter les outils GestSup.
Procédure de montage (Linux/macOS/Windows) dans le guide de démarrage.
Recherche dans les deux sens. De la doc vers la solution : obsidian_search
retrouve un problème/solution déjà consigné. Du ticket vers la doc :
gestsup_suggest_documentation (et la réponse de gestsup_close_ticket quand un
vault est configuré) propose de documenter en fin de ticket, mais détecte
d'abord si un cas similaire avec la même résolution est déjà en doc — auquel
cas il invite à ne pas créer de doublon (ou à compléter la note existante). La
détection de similarité est lexicale, déterministe et explicable ; le LLM tranche.
Une fois branché, tu pilotes GestSup en langage naturel ; l'assistant combine les outils :
Point quotidien sur mes tickets : « Fais le point sur mes tickets ouverts »
→ gestsup_search_tickets(technician_id=<moi>, exclude_state_ids=[<résolu/rejeté>])
puis synthèse (les ids d'états viennent de gestsup_list_referential kind=state).
Résumé d'un ticket : « Résume le ticket 1234 » → gestsup_get_ticket.
Tickets d'un demandeur : « Où en sont les tickets de Marie ? »
→ gestsup_find_tickets_by_user / gestsup_search_tickets(requester_id=…).
« Point infra » d'équipe : gestsup_search_tickets filtré par technicien(s)/groupe.
Agir : commenter, noter en interne, changer l'état/résoudre, affecter, mettre à jour (catégorie/priorité/temps), clôturer (conforme), créer un ticket.
Chercher une solution dans la doc : « A-t-on déjà eu ce souci d'imprimante ? »
→ obsidian_search (puis obsidian_read_note pour la fiche complète).
Capitaliser depuis un ticket : « Le ticket 1234 mérite-t-il d'être documenté ? »
→ gestsup_assess_ticket_quality ; si oui, « Documente-le » → gestsup_document_ticket
(article KB dans le vault). L'outil prévient si le ticket est trop pauvre.
Proposition en fin de ticket (anti-doublon) : après une clôture,
gestsup_suggest_documentation (ou directement la réponse de gestsup_close_ticket)
propose de documenter — sauf si un cas similaire avec la même résolution est
déjà en doc, où il invite à compléter la note existante plutôt qu'à en créer une.
Documenter une conversation : « Note dans la doc la procédure d'accès VPN »
→ obsidian_write_note / obsidian_append_section (sans ticket source).
Enrichir au fil du temps : « Ajoute à la note imprimante le cas du toner Lyon »
→ obsidian_append_section(path, heading, content).
Les outils de documentation sont conçus pour fonctionner avec n'importe quel
client MCP, Hermes agent en cible : transport stdio standard, schémas
d'outils classiques, résultats texte + JSON (pas de dépendance aux
fonctionnalités MCP optionnelles resources/prompts/sampling que certains
clients ne gèrent pas). L'accès au vault se fait par fichiers, sans exiger
qu'Obsidian soit lancé : il suffit que le serveur MCP ait accès au dossier du
vault.
API activée : Administration → Paramètres → Connecteurs → onglet API.
Une clé d'API générée.
Accès en HTTPS (l'API refuse tout port ≠ 443).
Si une liste blanche d'IP est configurée, l'IP du serveur MCP doit y figurer.
Pour les outils 🔌 : le plugin gestsup_mcp installé et activé
(voir plugin/gestsup_mcp/README.md).
npm install
npm run buildVariables d'environnement (voir .env.example) :
Variable | Requis | Défaut | Description |
| ✅ | — | URL de l'instance, sans |
| ✅ | — | Clé d'API GestSup (secret). |
| ✅* | — | Identité technicien : auteur des écritures et définition de « mes tickets ». Requis pour les écritures. |
| ❌ |
|
|
| ❌ |
| Timeout HTTP (ms). |
| ❌ |
|
|
| ❌ | — | Ids des types « incident » (cause obligatoire à la clôture), séparés par des virgules. À défaut, détection par le nom du type. |
| ❌ |
|
|
| ❌ | — | Racine du vault Obsidian (dossier local ou partage réseau monté : SMB/NFS…). Active les outils de documentation si défini. |
| ❌ |
| Sous-dossier des notes générées. |
| ❌ |
|
|
| ❌ |
| Score minimal (0-100) pour juger un ticket « documentable ». |
Dans claude_desktop_config.json :
{
"mcpServers": {
"gestsup": {
"command": "node",
"args": ["/chemin/absolu/vers/Gestsup-mcp/dist/index.js"],
"env": {
"GESTSUP_BASE_URL": "https://support.exemple.fr",
"GESTSUP_API_KEY": "votre-cle",
"GESTSUP_DEFAULT_USER_ID": "1"
}
}
}
}Sous Windows, utilisez des
/dans le chemin (ou doublez les\\). La version Microsoft Store de Claude Desktop lit sa config dans%LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\(pas dans%APPDATA%\Claude\).
Le dossier docker/ monte une instance GestSup jetable (données
d'exemple, plugin auto-installé et activé) :
cd docker
./fetch-source.sh
docker compose up -d --buildInterface web : http://localhost:8080 (admin / admin). Détails et branchement
du MCP : README du stack. Revalidation bout-en-bout :
test-integration/.
npm run typecheck # types
npm run lint # ESLint
npm run format # Prettier (écriture) ; format:check pour vérifier
npm test # tests unitaires (vitest, réseau simulé)
npm run build # compilation
npm run dev # compilation en watchCI : .github/workflows/ci.yml lance lint, format,
typecheck, tests et build (Node) + un lint de syntaxe PHP du plugin, à chaque
push et pull request.
Inspecter le serveur : npx @modelcontextprotocol/inspector node dist/index.js.
Version de référence : GestSup 3.2.55 (source = mirroir public
DeltaForce53/gestsup-3.2.55). Pour suivre une montée de version, voir le
runbook.
Le serveur gomme les pièges de l'API : décodage HTML, pagination par numéro de page, gestion des erreurs 403/404/405, kill-switch d'écriture.
La clé d'API n'est jamais journalisée.
MIT.
Ajoute un commentaire au fil d'un ticket. Un commentaire PUBLIC notifie le demandeur par mail (selon les paramètres GestSup) ; une NOTE INTERNE (internal=true) n'est pas visible du demandeur et n'envoie aucun mail. Nécessite le plugin serveur « gestsup_mcp ».
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texte du commentaire. | |
| time | No | Temps passé à enregistrer sur ce commentaire (minutes). | |
| notify | No | Pour un commentaire public : notifier le demandeur (par défaut oui). | |
| internal | No | true = note interne (privée, invisible du demandeur, sans mail). | |
| ticket_id | Yes | Numéro du ticket. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Covers notification difference, internal visibility, and plugin requirement. Missing error conditions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, type distinction, prerequisite. Front-loaded and succinct with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral distinctions and plugin requirement. Minor gap: no mention of return value or success/error handling, but adequate for a simple append tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description contextualizes parameters (public/internal, notification) but does not add new semantic details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (Ajoute) and resource (commentaire au fil d'un ticket), distinguishing public vs internal. Among siblings, this tool is uniquely for adding comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly clear for adding comments; explains public vs internal context. No explicit exclusions or alternative guidance, but purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Évalue si un ticket est assez RICHE et PROPRE pour alimenter la documentation. Récupère le ticket et renvoie un rapport déterministe : score (0-100), signaux (description, résolution, clôture, type, titre), verdict « documentable », et liste des MANQUES. À utiliser avant gestsup_document_ticket pour décider quoi capitaliser. Lecture seule.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes | Numéro du ticket à évaluer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the tool is read-only ('Lecture seule') and details the deterministic output, fully informing the agent of its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence clearly states purpose and outputs, second gives usage guidance and read-only note. Very concise and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 parameter, no output schema), the description is complete: it explains what the tool evaluates, what it returns, when to use it, and its read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter ticket_id is fully described in the schema (100% coverage). The description adds context that the tool retrieves the ticket and produces a report, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool assesses ticket quality for documentation, specifying the output (score, signals, verdict, shortcomings) and distinguishes itself from the sibling tool gestsup_document_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states 'À utiliser avant gestsup_document_ticket pour décider quoi capitaliser', providing explicit context for when to use this tool and how it relates to a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Affecte un ticket à un technicien OU à un groupe de techniciens. Fournir technician_id (voir gestsup_list_referential kind=technician) OU group_id (kind=group) — ids de l'instance, jamais devinés. Notifie le technicien/groupe affecté (paramètres GestSup). Nécessite le plugin « gestsup_mcp ».
| Name | Required | Description | Default |
|---|---|---|---|
| notify | No | Notifier l'affectation (selon paramètres GestSup). | |
| group_id | No | ID du groupe de techniciens à affecter (exclusif avec technician_id). | |
| ticket_id | Yes | Numéro du ticket. | |
| technician_id | No | ID du technicien à affecter (exclusif avec group_id). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose all behavioral traits. It mentions notification and plugin requirement, but does not address side effects (e.g., overwriting existing assignment) or error handling for invalid IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding critical information: main action, parameter usage, notification behavior, and plugin prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 4 parameters and no output schema, the description covers core behavior, exclusivity, and prerequisites. It could mention the return value or state change, but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining exclusivity of technician_id and group_id, and cross-referencing the list tool for obtaining IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: assigning a ticket to a technician or group. It specifies the two exclusive options (technician_id or group_id), which distinguishes it from sibling tools like create, close, or comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on providing either technician_id or group_id, and references another tool (gestsup_list_referential) to obtain valid IDs. However, it does not mention when not to use this tool or compare with other assignment methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clôture un ticket selon son type : un INCIDENT exige la CAUSE ET la RÉSOLUTION ; une DEMANDE exige au moins la RÉSOLUTION. La clôture est REFUSÉE si une obligation manque. La cause (si fournie) est ajoutée à la fin de la description du ticket ; la résolution est consignée. Résout le ticket et notifie le demandeur. Nécessite le plugin « gestsup_mcp ».
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Temps passé (minutes). | |
| cause | No | Cause (ajoutée en fin de description). Obligatoire pour un incident. | |
| notify | No | Notifier le demandeur de la clôture. | |
| ticket_id | Yes | Numéro du ticket. | |
| resolution | Yes | Résolution : ce qui a permis de résoudre. Obligatoire (incident ET demande). | |
| procedure_id | No | ID d'une procédure GestSup (kind=procedure), optionnel. | |
| procedure_text | No | Procédure en texte libre, optionnel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers validation logic, side effects (cause appended, resolution recorded, notification), and plugin requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, front-loaded with main purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (2 required) and no output schema, description covers validation, side effects, and dependencies but lacks return value info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds context for cause and resolution (obligations, appended/recorded), time unit, and default for notify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it closes a ticket and distinguishes between incident and request types with specific requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use and the conditional obligations, but does not explicitly name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crée un nouveau ticket de support dans GestSup. Renvoie l'identifiant et l'URL du ticket créé.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Titre / sujet du ticket (≤ 100 caractères). | |
| type_id | No | ID du type de ticket (voir gestsup_list_referential kind=type). | |
| description | Yes | Description détaillée du problème. | |
| requester_email | No | Email du demandeur ; rattache le ticket à l'utilisateur correspondant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the return values (ID, URL) but omits side effects, required permissions, or potential failure modes (e.g., duplicate detection). Schema covers validation constraints but not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with two sentences, front-loaded with the core action. Could be slightly improved by adding the return info upfront, but it is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers creation and return values but lacks details on required fields beyond what schema says, and does not address potential prerequisites (e.g., user authentication). For a tool with no output schema, the return description is helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a clear description. The tool description adds no extra semantic context, but the schema already explains the parameters adequately, including cross-reference for 'type_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a support ticket and returns the ID and URL. However, it does not distinguish this tool from 'gestsup_create_ticket_full', which is a sibling tool likely with broader functionality, missing an opportunity to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'gestsup_create_ticket_full' or 'gestsup_update_ticket'. There is no mention of prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crée un ticket complet (demandeur, catégorie, sous-catégorie, priorité, criticité, type, titre, description, temps, technicien/groupe, lieu). RECOMMANDÉ quand on part d'un email/d'une demande : 1) appeler gestsup_list_referential (type, category, subcat, priority, place…) pour connaître les valeurs RÉELLES de l'instance ; 2) DÉDUIRE du contenu les meilleurs ids (type incident/demande, catégorie, priorité, lieu/site) ; 3) confirmer avec l'utilisateur ; 4) créer. Les valeurs de liste sont des IDs (jamais devinés/inventés). Le demandeur est donné par requester_id OU requester_email. La création peut être REFUSÉE si des champs obligatoires définis dans GestSup manquent (le message indique lesquels). Notifie selon les paramètres GestSup. Nécessite le plugin « gestsup_mcp ».
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Temps passé (minutes). | |
| title | Yes | Titre du ticket. | |
| notify | No | Notifier (nouveau ticket) selon paramètres GestSup. | |
| type_id | No | ID de type (kind=type). | |
| group_id | No | Groupe assigné (kind=group). | |
| place_id | No | ID de lieu (kind=place). | |
| date_hope | No | Échéance souhaitée (YYYY-MM-DD). | |
| subcat_id | No | ID de sous-catégorie (kind=subcat). | |
| time_hope | No | Temps prévu (minutes). | |
| category_id | No | ID de catégorie (kind=category). | |
| description | Yes | Description. | |
| priority_id | No | ID de priorité (kind=priority). | |
| requester_id | No | ID du demandeur (tusers). | |
| technician_id | No | Technicien assigné (kind=technician). | |
| criticality_id | No | ID de criticité (kind=criticality). | |
| requester_email | No | Email du demandeur (résolu en utilisateur). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that creation can be refused with missing fields, notifies according to settings, and requires the plugin. However, it does not describe the return value (likely ticket ID), idempotency, or error handling beyond refusal. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of 6 sentences, front-loading the purpose then providing a workflow and rules. It is reasonably concise for the amount of information, though a structured list would improve scannability. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, no output schema, no annotations), the description explains purpose, usage, and error conditions but lacks information about return values, idempotency, and detailed parameter behavior. It provides a good foundation but leaves gaps that an agent would need to infer or discover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context by explaining that IDs must be real (from referential) and that requester can be specified by ID or email. However, it does not describe individual parameters beyond what the schema already provides. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a complete ticket and lists the fields. It implies a distinction from a simpler sibling by using 'complet' in the title and recommending this for email/request scenarios, but does not explicitly contrast with gestsup_create_ticket. The purpose is well-defined but sibling differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent usage guidelines: recommended when starting from an email/request, a step-by-step workflow (call referential, deduce IDs, confirm with user, create), and important rules like using real IDs and handling refusal. It explicitly names gestsup_list_referential as a preparatory tool and advises against guessing IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les tickets d'un demandeur (par son ID), avec tri et pagination. Renvoie une liste vide si aucun ticket.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Numéro de page (0 = première page). | |
| sort | No | Sens du tri. | DESC |
| limit | No | Nombre de tickets par page. | |
| order | No | Critère de tri. | date_create |
| user_id | Yes | ID du demandeur (tusers.id). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning an empty list if no tickets, which is helpful, but lacks details on permissions, rate limits, or side effects. For a read-only tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action, no extraneous text. Efficiently conveys essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 5 parameters and no output schema. The description covers the core behavior (list by user, sorting, pagination, empty list). It doesn't describe the return format in detail, but the schema already documents parameters. Given the coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats 'tri et pagination' which is already covered by parameters (sort, order, page, limit). It adds no new meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tickets by user ID with sorting and pagination, and distinguishes it from sibling tools like 'gestsup_search_tickets' (broader search) and 'gestsup_get_ticket' (single ticket). The verb 'Liste' and resource 'tickets d'un demandeur' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching tickets of a specific user, which is clear from context. However, it does not explicitly state when not to use it (e.g., for searching by other criteria) or mention alternatives explicitly, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère un ticket GestSup par son numéro, avec son fil de résolution (commentaires, changements d'état, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| ticket_id | Yes | Numéro du ticket. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns the ticket with its resolution thread, which is a read operation. However, it does not mention authentication requirements, rate limits, or any side effects. Since it is a read-only tool, the description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and includes key details (retrieves ticket, by number, with resolution thread). No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description adequately explains what the tool does and what it returns. It is sufficient for an agent to understand its usage. Could be improved by explicitly stating it returns the full ticket object, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for ticket_id ('Numéro du ticket.'). The tool description adds value by explaining that the ticket is retrieved by number and includes the resolution thread, but it does not add syntactic or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (récupère) and the resource (un ticket GestSup) with its identifier (par son numéro) and includes the additional context of returning the resolution thread (commentaires, changements d'état). This distinguishes it from sibling tools that create, update, or close tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a ticket by number, but it does not provide explicit guidance on when to use this tool versus alternatives like gestsup_search_tickets or gestsup_find_tickets_by_user. No exclusions or when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère la fiche d'un utilisateur GestSup par son ID.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | ID de l'utilisateur. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states retrieval with no disclosure of side effects, permissions, error behavior (e.g., user not found), or rate limits. Minimal behavioral context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description is minimally sufficient. However, it lacks details on return structure or behavior for missing users, which could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: parameter 'user_id' is described as 'ID de l'utilisateur.' Description adds no extra meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states verb (récupère), resource (fiche utilisateur), and parameter (par son ID). Clearly distinguishes from sibling tools which are all ticket-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives or any prerequisites. Sibling tools are ticket operations, so usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste un référentiel défini par l'instance GestSup : types, catégories, sous-catégories, lieux, états, priorités, criticités ou causes de résolution. Récupère les ID/valeurs RÉELS de l'instance (jamais codés en dur). À utiliser avant de créer/mettre à jour un ticket. (états/priorités/criticités/causes nécessitent le plugin « gestsup_mcp ».)
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Référentiel à lister. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool retrieves real IDs (not hardcoded) and mentions plugin dependencies for some referential kinds. However, it does not describe the output format, pagination, or whether the call has side effects (though reading is safe). Lacks details on what data the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose and then providing key usage guidance and constraints. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and no annotations, the description covers the essential: purpose, when to use, plugin caveats, and the nature of the output (real IDs). It is largely complete for a list tool, though specifying the response structure (e.g., array of objects) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'kind' with an enum and description. The description adds meaning by explaining that the tool returns actual instance IDs/values and that some kinds require a plugin. This goes beyond the schema's simple enumeration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a referential with a specific verb 'Liste' and resource 'un référentiel', enumerates the 11 possible kinds, and emphasizes it retrieves real IDs/values. This distinguishes it from other tools that create/update tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'À utiliser avant de créer/mettre à jour un ticket', providing clear when-to-use guidance. Also notes plugin requirements for some kinds. However, it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche/liste des tickets avec filtres (technicien, état, catégorie, demandeur, mots-clés, dates), tri et pagination. Permet notamment de lister les tickets d'un TECHNICIEN. Nécessite le plugin serveur GestSup « gestsup_mcp » installé et activé.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Numéro de page (0 = première). | |
| sort | No | Sens du tri. | DESC |
| limit | No | Tickets par page (max 200). | |
| order | No | Critère de tri. | date_create |
| date_to | No | Date de création maximale (YYYY-MM-DD). | |
| type_id | No | ID de type (kind=type). | |
| keywords | No | Recherche dans le titre et la description. | |
| place_id | No | ID de lieu / site (kind=place) — utile en multi-site. | |
| state_id | No | ID d'état du ticket. | |
| date_from | No | Date de création minimale (YYYY-MM-DD). | |
| subcat_id | No | ID de sous-catégorie. | |
| category_id | No | ID de catégorie. | |
| requester_id | No | ID du demandeur. | |
| technician_id | No | ID du technicien assigné (pour lister SES tickets). | |
| exclude_state_ids | No | États à exclure (ex. résolus) pour ne voir que les tickets ouverts. Récupérer les ids via gestsup_list_referential kind=state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes filtering, sorting, and pagination, which are read operations. However, it does not explicitly state that the tool is read-only or disclose any side effects. The plugin requirement is a useful behavioral note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the main action. It includes an important prerequisite without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search/list tool with no output schema, the description covers the input capabilities well. However, it does not describe the return format or structure (e.g., what fields are returned), which would be helpful for completion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented. The description adds value by emphasizing the technician_id use case and summarizing filter capabilities, but it does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recherche/liste des tickets avec filtres' and lists specific filter capabilities. It also highlights a key use case (listing technician tickets). However, it does not explicitly distinguish from siblings like gestsup_get_ticket or gestsup_find_tickets_by_user, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (plugin installed and activated) but does not provide guidance on when to use this tool versus alternatives (e.g., when a single ticket is needed vs. a list). The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change l'état d'un ticket (ex. résoudre, rejeter, mettre en cours…). L'état est un ID À RÉCUPÉRER via gestsup_list_referential kind=state (jamais deviné). Passer à l'état résolu enregistre la date de résolution. Notifie le demandeur selon les paramètres GestSup. Nécessite le plugin « gestsup_mcp ».
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Temps passé à enregistrer (minutes). | |
| notify | No | Notifier le demandeur (selon paramètres GestSup). | |
| comment | No | Commentaire/résolution à joindre au changement d'état. | |
| internal | No | true = le commentaire joint est une note interne (privée). | |
| state_id | Yes | ID de l'état cible (voir gestsup_list_referential kind=state). | |
| ticket_id | Yes | Numéro du ticket. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that setting to 'résolu' records a resolution date, notifies the requester according to GestSup settings, and requires the 'gestsup_mcp' plugin. It does not mention idempotency or other potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. It is front-loaded with the main action. While effective, it could be slightly more structured or broken into bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description covers the core purpose, side effects, and a critical parameter instruction. It lacks information on return values, error handling, or transactional behavior, but is still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and parameters have clear descriptions. The description adds critical value by specifying that state_id must be fetched and by explaining the side effect of setting the resolution date, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Change' and the resource 'l'état d'un ticket' with examples. It distinguishes the tool as a generic state changer, but does not explicitly differentiate it from siblings like gestsup_close_ticket which might be a specific case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs the agent to fetch the state ID via gestsup_list_referential and not guess it, providing clear context. However, it does not explicitly mention when not to use the tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Met à jour des champs d'un ticket : catégorie, sous-catégorie, priorité, criticité, type, temps passé/prévu. Les valeurs sont des IDs À RÉCUPÉRER via gestsup_list_referential (category/subcat/priority/criticality/type) — jamais devinés. Notifie le demandeur selon les paramètres GestSup. Nécessite le plugin « gestsup_mcp ».
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Temps passé total (minutes). | |
| notify | No | Notifier le demandeur (selon paramètres GestSup). | |
| type_id | No | ID de type (kind=type). | |
| place_id | No | ID de lieu / site (kind=place) — utile en multi-site. | |
| subcat_id | No | ID de sous-catégorie (kind=subcat). | |
| ticket_id | Yes | Numéro du ticket. | |
| time_hope | No | Temps prévu (minutes). | |
| category_id | No | ID de catégorie (kind=category). | |
| priority_id | No | ID de priorité (kind=priority). | |
| criticality_id | No | ID de criticité (kind=criticality). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses notification behavior and plugin dependency, but omits details on permissions, reversibility, or whether updates affect only specified fields. This is acceptable but not comprehensive for a mutation tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three focused sentences: function, critical ID retrieval advice, then notification and plugin note. It is front-loaded and concise without extraneous words. Minor improvement would be to place plugin requirement earlier, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description covers the core purpose and a key prerequisite but lacks details on update behavior (partial updates, state dependencies, error conditions). It is adequate but not complete for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 10 parameters with descriptions. The description adds value by grouping fields and emphasizing ID retrieval from referential, but does not provide syntax or format details beyond the schema. At 100% schema coverage, baseline is 3, and the description adds marginal extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates ticket fields like category, subcategory, priority, etc. It mentions the need to retrieve IDs via a sibling tool, which adds specificity. However, it does not explicitly distinguish from similar update tools like assign_ticket or set_ticket_state, though the sibling list aids inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'IDs must be retrieved from gestsup_list_referential — never guessed'. It also mentions notification behavior and plugin requirement. However, it lacks when-to-use vs alternatives such as assign_ticket or set_ticket_state, and does not state prerequisites like ticket state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0gestsup_add_ticket_commentgestsup_assess_ticket_qualitygestsup_assign_ticketgestsup_close_ticketgestsup_create_ticketgestsup_create_ticket_fullgestsup_find_tickets_by_usergestsup_get_ticketgestsup_get_usergestsup_list_referentialgestsup_search_ticketsgestsup_set_ticket_stategestsup_update_ticketScored across 13 tools
Each tool targets a distinct action on tickets or users, with no overlap. Even create_ticket and create_ticket_full are clearly differentiated by detail level.
All tools follow a consistent 'gestsup_verb_noun' snake_case pattern, with clear verbs like add, assign, close, create, get, list, search, set, update. Excellent naming discipline.
13 tools cover the essential ticket lifecycle (create, read, update, close, assign, comment, search, referential lookup) without being excessive. Each tool serves a necessary purpose.
Core CRUD and ticket management are well-covered. Minor gaps include lack of a delete/archive tool and no attachment handling, but the surface is sufficient for typical support workflows.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
