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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds only that the whole record is returned (no partial field selection) and nothing about permission requirements or behavior on unknown id.

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?

A single front-loaded sentence with no wasted words, though its brevity edges toward under-specification rather than crispness.

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 no output schema, the description must carry the return-shape burden; 'full record' is the only hint and there is no mention of field format, error behavior for a bad id/itemtype, or permissions. For a generic polymorphic getter over many itemtypes, this leaves real gaps.

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 50%: itemtype is documented with a useful enum-like example list, but 'id' carries no description in either the schema or the description. The description contributes nothing about parameter semantics, leaving the undocumented half uncompensated.

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?

States a specific verb and resource ('Full record of one item of any itemtype') and enumerates the breadth of itemtypes, which distinguishes it from list/search siblings like glpi_search_items and glpi_list_items. It does not explicitly say it returns a single record by id, but 'one item' plus 'full record' conveys that.

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?

There is no when-to-use guidance and no mention of alternatives such as glpi_get_ticket (a specialisation), glpi_search_items (when the id is unknown), or glpi_raw_get. The agent must infer that this is the id-known single-record read.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that timeline and team are optional expansions and enumerates their contents, but says nothing about behavior on a missing id, error responses, or how expensive the expansions are.

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 sentences, both front-loaded and content-bearing. The core fetch is stated first, followed by the optional expansions, with no filler.

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?

This is a read-only fetch with no output schema, and the annotations carry the safety profile. The description covers the core return content and both optional expansions, leaving only error/id-not-found behavior unstated, which is minor for a lookup 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 description coverage is only 25% (only itil_type is documented in the schema), so the description must compensate. It does so for the two booleans by defining what timeline (followups, tasks, solutions) and team (requesters, technicians, groups, observers) actually contain, which meaningfully clarifies what those flags return. It omits the default values and the id semantics, but the schema covers those.

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?

States a specific verb and resource: 'Full details of one ticket (or change/problem)', with the optional timeline and team expansion spelled out. It implicitly distinguishes itself from the generic glpi_get_item by being ITIL-object specific, but never names that sibling to make the distinction explicit.

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?

Usage is implied rather than stated: fetch one record by known id. It gives no guidance on when to prefer this over glpi_get_item, glpi_search_tickets, or glpi_raw_get, and no prerequisites or exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds only the fact that results are paginated; it says nothing about invalid-itemtype behavior, ordering of results, or cost of open-world calls beyond what annotations imply.

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?

A single short sentence with the resource and pagination front-loaded and no wasted words. It is efficient, though it borders on under-specification given the available sibling tools to disambiguate against.

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 simple read-only paginated list tool with annotations and no output schema, the description covers the essentials but omits the return shape (what fields an item entry contains) and does not resolve overlap with glpi_search_items. Adequate but with clear gaps.

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?

With 67% schema coverage, itemtype and start are already documented in the schema (including a rich list of valid itemtype values), while limit is documented only by type/bounds/default. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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 states a specific verb and resource ("List items"), scopes it to one itemtype, and adds a concrete example ("all Computers"), plus notes pagination. It does not differentiate from the close sibling glpi_search_items, which likely also enumerates items, leaving the agent to infer the list-vs-search distinction.

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?

There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as glpi_search_items (filtered search) or glpi_get_item (single record). Only the passing example "e.g. all Computers" hints at intent, so the agent must infer routing from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. Beyond that, the description discloses genuinely useful behaviour the annotations cannot: paths are relative to the API root, two different API generations exist with different path shapes, and glpi_server_info tells you which one applies. Error handling and response shape remain undisclosed.

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 compact sentences, front-loaded with the core concept before the examples. Every clause carries information an agent needs — the escape-hatch framing, the path grammar for both API modes, and the pointer to the discovery tool.

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 two-parameter open-world passthrough with no output schema, this covers the essential unknowns: how to construct the path and how to learn which API is live. It does not mention pagination on 'search' endpoints or what a failure returns, which are the main remaining gaps for arbitrary-endpoint calls.

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 50% and the undocumented parameter is the important one — 'path' has no schema description at all. The description compensates well with concrete path examples for both legacy ('Ticket/12/Document_Item', 'search/Computer', 'listSearchOptions/Ticket') and high-level ('Assets/Computer/5', 'Administration/User/Me') forms, and shows the query shape as {criteria: [...]}.

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?

States a specific verb and resource — a raw, read-only GET against any endpoint of whichever GLPI API is active, relative to its root — and frames the tool as an 'escape hatch', which immediately separates it from the curated siblings like glpi_get_item or glpi_search_items.

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 phrase 'escape hatch' plus the instruction to call glpi_server_info first makes the when-to-use condition explicit: reach for this only when no high-level tool covers the endpoint, and confirm which API flavour is active before building a path. It stops short of naming the specific sibling to prefer for common cases (e.g. 'for tickets use glpi_get_ticket'), which keeps it at 4.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond that: matching is partial rather than exact, itemtype is open-ended, and the response contains IDs rather than full records. It does not mention result capping or pagination behavior, which is the remaining gap.

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 sentences with no filler, and the most decision-relevant information (what it searches, then what it returns and how to use it) is front-loaded. Nothing repeats the title or wastes tokens.

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 no output schema, the description correctly states the return content (IDs) and the follow-up tools, which is the key missing piece an agent would otherwise lack. For a four-parameter, non-nested search tool with rich annotations, this is nearly complete; only pagination and result-limit behavior are unaddressed.

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 50%: itemtype and start carry descriptions, while query and limit have none. The description compensates for query by specifying name-based partial matching, but adds nothing for limit or pagination, and its itemtype examples largely restate the schema description. This is a baseline-plus contribution, not full compensation.

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?

"Find assets, users, groups, locations, categories, suppliers, KB articles or any other itemtype by name (partial match)" gives a specific verb and a wide resource enumeration, so an agent knows this is the generic itemtype search. It is distinguishable from glpi_search_tickets and glpi_search_knowledgebase only implicitly through "any other itemtype", rather than by naming those siblings directly.

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 second sentence names the downstream tools (glpi_get_item or the ticket tools) and states that the output is IDs for them, which gives clear workflow context. It stops short of explicit exclusions such as "use glpi_search_tickets for ticket text search", so the choice between this and the specialized search siblings is left partly to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The one genuinely additive behavioral fact is that matching is on titles only, not article bodies, which sets expectations about recall; beyond that it adds no return-shape or pagination 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?

Two short sentences, front-loaded with the action and followed by the natural next step; nothing is wasted. The phrasing is slightly compressed ('whose title matches the text') where a few more words would remove ambiguity about case or partial matching.

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 simple read-only search with no output schema, this covers what the tool finds and how to retrieve a full record. It omits what a result row contains (IDs, itemtype) and whether matching is substring or exact, which an agent must learn by calling it.

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 33%, and the description compensates for the most important parameter by explaining that 'query' matches against article titles. The limit and start parameters get no attention beyond the schema's pagination note on 'start', and the title-only matching constraint is easy to miss.

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 names a specific verb and resource ('Find knowledge base articles') and narrows the scope to title matching, which is more precise than the tool name alone. It does not differentiate itself from the sibling glpi_search_items, leaving the agent to infer why a dedicated knowledge-base search exists.

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 gives an explicit follow-up path: read a result with glpi_get_item using itemtype KnowbaseItem, which is exactly the guidance needed after a search. It stops short of stating when to prefer this over glpi_search_items or when not to use it at all.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: result ordering ('newest change first'), the compact-summary return shape, and the legacy-API constraint on assignee/requester filters. It omits pagination behavior and any note on result volume, keeping it from a 5.

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?

Front-loaded with purpose and ordering before the ID lookup tables, and every sentence carries usable information. The inline ID enumerations are dense but justified for a tool whose schema lacks those descriptions; minor cost is readability of the middle block.

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 12-parameter, zero-required search tool with no output schema, the description covers ordering, return shape, filter semantics and one important API caveat. Gaps remain around pagination (limit/start) and what the ID-based user/group/category parameters accept, but nothing critical to a correct first call is missing.

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 50%, so the description must compensate, and it does: it enumerates status IDs (1-6), priority IDs (1-6 with 'major'), and ticket_type values (1 incident, 2 request). Undocumented parameters remain (category_id, assigned_user_id, assigned_group_id, requester_user_id, priorities, limit), so it does not fully close the gap.

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?

Opens with a specific verb and resource: 'List tickets (or changes/problems)... with a compact summary of each', and explicitly scopes itself as the list-level tool versus glpi_get_ticket for single-item detail. An agent can distinguish it from siblings without opening the schema.

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 routes the agent to glpi_get_ticket 'for the description, timeline and team of one item', and flags that assignee/requester filtering 'works on the legacy API only'. It does not differentiate itself from glpi_search_items or glpi_list_items, which are close siblings, so it falls short of a full when/when-not map.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile of the call itself is covered. The description adds value beyond that by disclosing the payload contents and, importantly, the server-side safety modes (read-only, delete allowed), which an agent needs before deciding whether mutating tools are usable. Minor gap: no note on failure behavior when the server is unreachable.

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 sentences with zero filler. The return contents come first and the usage instruction is front-loaded at the end as an imperative, which is exactly the order an agent needs.

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 no output schema, the description carries the burden of explaining return values and does so explicitly (API flavor, pinned version, URL, safety modes). Combined with the diagnostic trigger, an agent has everything needed to call it and interpret the result.

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 tool takes zero parameters, so the schema imposes nothing to interpret and the baseline is 4. The description correctly implies a parameterless probe and adds no misleading input expectations.

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?

States a specific verb ("Show") and enumerates exactly what is reported: which API flavor (legacy REST vs High-Level API) with its pinned version, the GLPI URL, and the active safety modes. This is clearly distinguishable from sibling tools like glpi_whoami or glpi_search_tickets, which retrieve identity or records rather than connection/config metadata.

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?

"Call it first when a connection problem is suspected" gives an explicit trigger condition and a priority ordering relative to other tools. It stops short of stating when-not to use it or naming a specific alternative, so it is clear context rather than a full decision tree.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld. The description adds genuinely new context beyond them: that all other tool calls execute under this identity's rights, which is important authorization information. It does not describe the return shape, but with no output schema that is a minor gap.

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 with no filler, and the key identity statement is front-loaded. The first sentence is a grammatical fragment, which slightly weakens readability but not economy.

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 zero-parameter, read-only introspection tool with no output schema, the description covers what it returns (user, active profile, entity) and why it matters (rights scoping). Only the exact response fields remain unspecified.

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?

Zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies the tool takes no input and reads ambient session state.

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 identifies a specific resource — the GLPI user the tools act as, plus the active profile and entity — which no sibling tool covers, so there is no selection ambiguity. It is phrased as a noun fragment rather than a verb+resource ('returns the current user'), which keeps it just 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.

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

There is no explicit when-to-use statement or named alternative. The second sentence ('Every call runs with that user's rights') implies the sensible use case — verifying identity/permissions before other calls — but the agent must infer it.

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