Skip to main content
Glama

Get group

glpi_get_group
Read-onlyIdempotent

Retrieve a group by ID.

Input Schema

NameRequiredDescriptionDefault
fieldsNoField set: 'essential' (default, trims internal GLPI fields) or 'all'
formatNoOutput format: 'json' (default) or 'markdown' (a table for listings, key/value lines for one item; returned in both the text and the structured result)
groupIdYesItem ID

Output Schema

NameRequiredDescriptionDefault
dataNo
noteNoPagination hint: how to fetch the next page
countNoItems in this page
formatNo'markdown' when data holds the markdown rendering

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds nothing on top of that – no note about what a missing group returns, permission needs, or the effect of the fields/format options.

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

Conciseness4/5

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

A single front-loaded sentence with zero filler, which is proportionate for a simple one-ID lookup. It is arguably under-specified rather than padded, but from a conciseness standpoint nothing is wasted.

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?

With a 100%-documented schema, an output schema, and rich read-only annotations, the essentials for correct invocation are externally covered. The description contributes no extra completeness — no sibling routing and no mention of the fields/format trade-offs — so it is minimum viable for an otherwise simple tool.

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%, and 'fields' and 'format' are each documented with defaults and enum meanings in the schema itself, so the baseline of 3 applies. 'Retrieve a group by ID' adds no syntax or semantic detail beyond the schema's own 'Item ID' description.

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 (Retrieve) and resource (a group) scoped by ID, so an agent immediately knows this is a single-item fetch. It does not differentiate from the sibling glpi_list_groups (collection listing) or explain how it relates to the other glpi_get_* single-item tools, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance at all: no condition for choosing this over glpi_list_groups, no note that it is the read counterpart to group creation/update tools. The only implied hint is 'by ID', leaving routing entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.