GLPI MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GLPI_URL | Yes | Base URL of your GLPI instance (without trailing slash) | |
| GLPI_LANG | No | Label language: fr or en | fr |
| GLPI_VERSION | No | GLPI version: 10 or 11 | 10 |
| GLPI_APP_TOKEN | Yes | App-Token created in GLPI API configuration | |
| GLPI_USER_TOKEN | Yes | User-Token from your GLPI account |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| kill_sessionA | Ferme proprement la session GLPI active. |
| list_ticketsC | Liste les tickets avec pagination optionnelle.
|
| get_ticketB | Retourne le détail complet d'un ticket, avec libellés lisibles. |
| search_ticketsC | Recherche avancée de tickets via l'API GLPI /search/Ticket. Tous les paramètres sont optionnels et combinables. |
| create_ticketB | Crée un nouveau ticket.
|
| update_ticketA | Met à jour un ticket. Passer uniquement les champs à modifier. Exemples de champs : status, priority, name, content, itilcategories_id |
| delete_ticketB | Supprime un ticket par son ID. |
| link_ticketsB | Crée un lien entre deux tickets.
|
| list_ticket_linksB | Liste tous les liens d'un ticket avec d'autres tickets. |
| merge_ticketsA | Fusionne un ou plusieurs tickets source vers un ticket cible.
Paramètres :
|
| list_itil_categoriesA | Liste toutes les catégories ITIL disponibles (Incident, Demande, Changement, Problème). |
| list_followupsB | Liste tous les suivis d'un ticket. |
| add_followupA | Ajoute un suivi à un ticket.
|
| get_followupB | Retourne le détail d'un suivi spécifique. |
| list_tasksA | Liste toutes les tâches d'un ticket. |
| add_taskB | Crée une tâche sur un ticket.
|
| update_taskA | Met à jour une tâche. Exemples : state (1/2), content, actiontime, users_id_tech |
| delete_taskC | Supprime une tâche. |
| get_solutionC | Retourne la solution d'un ticket. |
| add_solutionA | Poste une solution sur un ticket (le clôture automatiquement selon la config GLPI).
|
| stats_by_statusA | Retourne le nombre de tickets ouverts par statut. |
| stats_by_typeA | Retourne le nombre de tickets par type (Incident / Demande de service). |
| stats_by_priorityA | Retourne le nombre de tickets ouverts par priorité. |
| stats_by_categoryA | Retourne le nombre de tickets par catégorie ITIL. |
| stats_by_assigneeA | Retourne le nombre de tickets par technicien assigné. |
| stats_resolution_timeA | Retourne le délai moyen de résolution des tickets résolus ou clos. |
| stats_overdueA | Retourne les tickets en retard (date d'échéance dépassée et non résolus). Utilise le champ time_to_resolve de GLPI. |
| get_usersB | Liste les utilisateurs GLPI. |
| get_groupsA | Liste les groupes GLPI. |
| list_kb_articlesA | List GLPI knowledge base articles with pagination. Each KnowbaseItem returned by the API embeds the full HTML answer. On large KBs this makes the JSON response heavy: in production we observed that range_start > 60 combined with range_limit > 10 is enough to exceed PHP-FPM memory_limit on the GLPI side and the request fails. To stay below that ceiling, range_limit is auto-clamped to 10 when range_start > 60. When clamping kicks in the response is wrapped in a dict carrying _clamped_range_limit and _warning so callers can detect the change. Behaviour is unchanged for range_start <= 60. |
| get_kb_articleB | Retourne le detail complet d'un article de la base de connaissances. |
| search_kb_articlesA | Search knowledge base articles by keyword. By default the search runs only against the title column, which is fast on any GLPI instance. Set search_content=True to also match against the full HTML body. On a GLPI instance that has no MySQL FULLTEXT index on knowbaseitems.answer, that branch produces a LIKE '%keyword%' scan on the answer column which routinely exceeds the 30 second client timeout on KBs with sizeable HTML payloads. Field IDs are discovered at runtime via listSearchOptions/KnowbaseItem and looked up by column name ("name", "answer") so the tool works on both GLPI 10 and GLPI 11 (where numeric IDs may differ). When discovery fails the legacy GLPI 10 IDs (6 for title, 7 for body) are used as a fallback. Parameters:
|
| create_kb_articleA | Cree un nouvel article dans la base de connaissances.
|
| update_kb_articleB | Met a jour un article de la base de connaissances. Exemples de champs : name, answer, is_faq, knowbaseitemcategories_id |
| list_kb_categoriesA | Liste toutes les categories de la base de connaissances. |
| get_kb_article_visibilityA | Retourne les regles de visibilite d'un article KB : profils, groupes, utilisateurs et entites ayant acces. |
| add_kb_article_visibility_profileA | Ajoute un profil dans la visibilite d'un article KB.
|
| add_kb_article_visibility_groupC | Ajoute un groupe dans la visibilite d'un article KB.
|
| update_kb_article_visibility_profileA | Met a jour une regle de visibilite par profil d'un article KB.
|
| update_kb_article_visibility_groupA | Met a jour une regle de visibilite par groupe d'un article KB.
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 40 tools
Most tools have clearly distinct purposes, such as ticket CRUD, task management, and KB operations. However, list_tickets and search_tickets overlap in functionality since search_tickets can replicate simple listing with filters, and link_tickets vs list_ticket_links are create vs read but names are close.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., list_tickets, create_ticket, update_ticket. The stats_by_* tools form a coherent sub-pattern, and even kill_session fits the verb_noun convention.
40 tools is excessive according to the rubric (25+ is too many). The visibility management tools alone add 8 variations, and many tools handle niche edge cases that could be consolidated or omitted without losing core functionality.
The ticket lifecycle is well covered with CRUD, linking, merging, followups, and tasks. However, there are notable gaps: no delete for KB articles, no update/delete for followups or solutions, and no deletion of visibility rules, which could leave users unable to correct mistakes or remove obsolete data.