Skip to main content
Glama
Sign In
GLPI MCP

GLPI MCP

by USONDIG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

update_task

Update an existing GLPI task's state, content, action time, or assigned technician through the REST API.

Instructions

Met à jour une tâche. Exemples : state (1/2), content, actiontime, users_id_tech

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": {
      "task_id": "<task_id>",
      "update_fields": "<update_fields>"
    },
    "name": "update_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYes
update_fieldsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior2/5

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 only states that the tool updates a task and lists example fields, without disclosing side effects, permissions, error behavior, or whether the update is partial or full, leaving significant behavioral context unknown.

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?

The description is extremely concise and front-loaded: a single action sentence followed by a short list of examples. Every word earns its place, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an open-ended update_fields object, no output schema, and no annotations. The description provides only a few examples without explaining update semantics (e.g., partial vs full update), error cases, or return behavior, leaving notable gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds value beyond the schema by listing example keys (state, content, actiontime, users_id_tech) and hinting at valid values for state (1/2). Since update_fields is an arbitrary object with no schema descriptions, these examples help clarify expected structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Met à jour une tâche' (Updates a task) and gives example fields, making the tool's purpose specific and distinct from siblings like add_task, delete_task, and update_ticket.

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 description implies this tool is for modifying existing tasks but does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites, exclusions, or when not to use it. The examples hint at usage but provide no explicit guidance.

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