NexTool MCP for GLPI

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds nothing beyond: it doesn't disclose whether followers are notified, how private vs public works, or side effects on the change timeline.

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 no waste and the action front-loaded. It is efficient, though the extreme sparseness means there is little structure to speak of.

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?

An output schema exists, so return values need not be explained, and params are fully covered by the schema. But for a mutating tool in a crowded sibling family, the absence of any usage or behavioral context 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 description coverage is 100%, so the schema already documents changeId, content, and the is_private enum meaning (1=private, 0=public). The description adds no parameter meaning beyond the schema, so the baseline 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?

States a clear verb+resource: 'Add a comment/followup to a change.' An agent understands the action and target. However, it does not distinguish this from closely-named siblings like glpi_add_followup (generic) or glpi_add_change_solution, so the differentiation is missing.

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 when-to-use guidance, no exclusions, and no mention of alternatives. With three near-identical followup tools (change, problem, generic) plus change solutions, the description leaves the agent to guess which one applies.

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 declare the safety profile (readOnly=false, destructive=false, non-idempotent, openWorld), and the description adds a genuinely useful trait beyond them: the change's status is set to Solved as a side effect. It stops short of noting what happens if a solution already exists (non-idempotent overwrite risk) or any permission requirements.

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 sentence with no filler, and the side-effect disclosure is placed inline rather than buried. Every word earns its place.

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 an output schema present, return values need not be explained, and both required parameters are fully covered by the schema. The description is complete for invocation purposes, though it lacks any routing guidance relative to the many sibling solution/followup tools.

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 both parameters (changeId, content) are documented in the schema, so the baseline is 3. The description adds no format, validation, or usage nuance for either parameter.

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 ("Add a solution to a change") and the parenthetical discloses the resulting state change. It does not explicitly distinguish itself from near-name siblings like glpi_add_solution or glpi_add_problem_solution, so it falls 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?

No guidance on when to use this instead of glpi_add_solution, glpi_add_problem_solution, or glpi_update_change. The agent must infer from the tool name alone which resource/solution variant applies.

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=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds no behavioral context of its own — nothing about whether the followup triggers notifications, whether it is visible to requesters, or permission requirements.

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 zero padding. It is efficient, though the brevity borders on under-specification rather than genuine conciseness.

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 an output schema present and full annotation coverage, the description need not explain return values. However, for a write operation with four parameters and three near-identical followup siblings, it omits the disambiguation and side-effect context an agent would need to call it correctly.

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 all four parameters (content, ticketId, users_id, is_private) are already documented in the schema, including the private/public default. The description adds no meaning beyond the schema, so the baseline 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?

States a specific verb (add) and resource (comment/followup) scoped to a ticket, which is clear on its own. It does not explicitly differentiate from the close siblings glpi_add_change_followup and glpi_add_problem_followup, relying on the tool name to carry that 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?

No guidance on when to use this versus the change/problem followup variants, nor when to prefer a solution (glpi_add_solution) over a followup. No prerequisites or exclusions are stated.

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=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds nothing on top of that: it does not say whether the followup is public or private by default, who can see it, or that the problem must already exist. For a mutation tool at this bar, the description contributes no behavioral context.

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?

One short, front-loaded sentence with zero filler, which is the right shape. It is efficient but so terse that it reads as under-specified rather than deliberately compact.

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?

An output schema exists, so return values need not be explained, and the schema fully covers the three parameters. However, for a non-idempotent write tool in a family with several near-identical 'add followup' siblings, the description leaves the agent without routing or visibility guidance, which is a real gap relative to the context's complexity.

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 problemId, content and is_private (1=private, 0=public) are all documented structurally; the schema baseline of 3 applies. The phrase 'comment/followup' loosely clarifies what content represents, but no default for is_private or relationship between the two required params is added.

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 gives a concrete verb plus resource ('Add a comment/followup to a problem'), which clearly separates it from the get/list/problem-update siblings. It stops short of distinguishing itself from the other additive siblings that share its name pattern (glpi_add_followup, glpi_add_change_followup, glpi_add_problem_solution), so the agent must infer the split from the name alone.

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 language, no prerequisites, and no alternatives named. The sibling set contains glpi_add_problem_solution and a generic glpi_add_followup, and the description does nothing to tell the agent which of these is correct for a given intent.

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 non-read-only, non-destructive, non-idempotent behavior. The description usefully adds the side effect that the problem status changes to 'Solved', which is not encoded in annotations. However, it omits auth requirements, error/validation conditions, and re-solve semantics, so it adds only partial behavioral context.

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 zero filler that states the action and its most important consequence immediately.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The mutation's key side effect is noted, but the description is thin on when to choose this over sibling solution tools and on any state prerequisites, leaving gaps for an agent acting among many similar tools.

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 both parameters (problemId, content) are already fully documented in the schema. The description adds no additional meaning about parameter format or constraints, so the baseline 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 ('Add a solution to a problem'), which is clearly distinct in name from the generic glpi_add_solution and glpi_add_change_solution siblings. It does not explicitly explain how it differs from the generic add_solution tool, so it falls 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 guidance on when to use this tool versus the sibling glpi_add_solution or glpi_add_change_solution, nor any prerequisites such as the required problem state before a solution can be added. The agent must infer usage from the 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=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is covered. The description adds one genuinely useful fact not in the annotations: the ticket status transitions to Solved. It says nothing about permissions required, whether an existing solution is replaced, or reversibility.

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 sentence with zero filler, and the side effect is front-loaded within the parenthesis. It is efficient but borderline terse given the behavioral gaps that remain.

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 only two required params, full schema coverage, an output schema, and annotations covering the safety profile, most of the burden is carried by structured fields. Still missing are the conditions for a valid call (e.g., ticket must exist and be in a solvable state) and whether repeated calls stack multiple solutions, which matters given idempotentHint=false.

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%, with both ticketId and content documented in the schema, so the baseline of 3 applies. The description adds no format, length, or validation detail beyond what the schema already provides.

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 ("Add a solution to a ticket") plus the resulting state change, which is more than the title alone. It implicitly scopes to tickets versus the change/problem solution siblings (glpi_add_change_solution, glpi_add_problem_solution), but never names those alternatives explicitly, so an agent must infer the routing.

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 only implied: adding a solution signals ticket resolution, and the parenthetical clarifies the terminal effect. There is no explicit when-to-use, no prerequisites, and no mention of the sibling tools that add solutions to changes or problems.

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=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the mutation/safety profile is covered structurally. The description adds the role semantics of the type field, but that information is duplicated in the schema rather than adding new behavioral context such as ordering, duplicate handling, or permission requirements.

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 compact sentences with the core action front-loaded and no filler. The second sentence restates the type mapping already present in the schema, which is minor redundancy rather than bloat.

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 only three fully documented parameters, a present output schema, and annotations covering the safety profile, the description supplies everything an agent needs to invoke the tool correctly. The only gap is that it never distinguishes this from glpi_add_ticket_user.

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 the schema alone documents all three parameters, including the same '1=Requester, 2=Assigned, 3=Observer' mapping the description repeats. Baseline 3 applies since the description contributes no meaning beyond the structured fields.

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 ('Add a group to a ticket') and enumerates the three relationship roles, so the agent knows exactly what the operation creates. It is clear without opening the schema, though it does not explicitly name the adjacent sibling glpi_add_ticket_user as the alternative for individual users.

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 by the name and the role list, but there is no explicit when-to-use guidance, no statement of the alternative (glpi_add_ticket_user) or exclusion. An agent must infer that this tool is for groups and the sibling is for individual users.

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=false, idempotent=false, destructive=false, and openWorld=true, so the safety profile is covered by structured data. The description adds field semantics but discloses nothing about side effects, required permissions, or what happens to ticket state when a task is added, leaving the annotation bar only partially met.

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 compact single block with the core purpose front-loaded and required fields flagged before optional ones. It is efficient, though the terse field dump reads more like a schema echo than a curated summary.

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 an output schema present and 100% parameter coverage, the description need not explain return values, and it covers the required/optional split adequately for a straightforward create operation. It is only slightly thin on prerequisites and error conditions for a mutation 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 100%, so the schema already documents every parameter, and the description's field list (including the state and is_private codes) largely restates it. It adds no format, validation, or default details beyond what the schema provides, 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 ('Add a task to a ticket') and enumerates the fields it accepts, so an agent can immediately tell it is a task-creation tool. However, it does not differentiate from close siblings like glpi_add_followup or glpi_add_solution, which also attach content to a 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?

There is no when-to-use guidance, no prerequisites (e.g. the ticket must exist), and no pointer to the alternative tools such as glpi_add_followup or glpi_list_ticket_tasks. Usage must be inferred entirely from the name.

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 the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true). The description adds no behavioral context beyond that — no note on duplicate-user handling, permissions, or side effects — and merely restates the schema's type mapping.

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 compact sentences, front-loaded with the operation and immediately followed by the role-value mapping. Slightly redundant with the schema, but no wasted preamble.

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?

A simple 3-parameter mutation with full schema coverage, annotations covering the safety profile, and an output schema that handles return values. The only gap is absence of prerequisite/permission context, which is minor for this operation.

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 all three parameters (tickets_id, users_id, type) are already documented. The description's type mapping duplicates the schema's enum explanation rather than adding new meaning, so the baseline 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?

States a specific verb (add), resource (user), and target (to a ticket), plus the three role values that define scope. An agent can distinguish it from glpi_add_ticket_group and glpi_add_ticket_task purely from the name/description.

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 when-to-use guidance, no prerequisites (e.g., ticket must exist), and no mention of alternatives such as glpi_update_ticket for changing an existing assignment. The role definitions hint at intent but don't route the agent between tools.

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 declare destructiveHint=true, idempotentHint=false and openWorldHint=true; the description only reinforces the session scope ('for the current session') and does not explain why the operation is flagged destructive or that it mutates context for every subsequent call in the session. That is a meaningful gap given the strong destructive annotation, though the session-scope statement does add context beyond the annotations.

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 short sentences, front-loaded with the core action and no wasted words. The middle sentence is slightly promotional ('Essential...') but still conveys useful context rather than 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?

An output schema exists, so return values need not be described, and both parameters are fully documented. For a simple session-switch operation the description is nearly complete; the only shortfall is not explaining the consequences of the destructive/idempotent flags it carries.

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 entityId and is_recursive are already documented in the schema. The description's 'Use is_recursive=true to include sub-entities' largely restates the schema description ('Include sub-entities (default: false)'), adding only a usage framing. Baseline 3 applies when the schema does the heavy lifting.

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+resource (change active entity) and adds the crucial scope qualifier 'for the current session,' which separates it from glpi_update_entity and glpi_get_entity. It does not explicitly name a sibling alternative, but the session-scoping makes the target distinct enough for an agent to pick correctly.

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?

'Essential for multi-entity GLPI instances' implies when the tool matters, giving the agent a context trigger. However, it never states when to call it versus glpi_get_my_entities or glpi_get_full_session, nor any prerequisites (e.g., needing rights to the target entity). Usage is implied rather than instructed.

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 elsewhere. The description adds genuinely new behavioral context: no record payload is transferred and the operation is cheap, which matters for an agent choosing between counting and listing. It does not mention the shape or limits of the returned count, but the output schema presumably covers that.

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 compact sentences, front-loaded with the core distinction (counting without transfer) and followed by the one operational hint. No filler or restatement of the title.

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 rich annotations, a 100%-covered two-parameter schema, and an existing output schema, the description supplies exactly the missing pieces: the count-vs-transfer distinction and how to obtain criteria field IDs. Nothing needed to select or invoke the tool correctly is absent.

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%, both parameters are documented, and the criteria shape is cross-referenced to glpi_search. The description goes beyond the schema by pointing to glpi_list_search_options as the way to discover valid criteria field IDs, which is actionable value the schema does not supply.

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 (count items) and immediately distinguishes itself from the list/search siblings by saying it counts 'without transferring them'. The parenthetical 'answers "how many" in one cheap call' removes any ambiguity about what the tool returns.

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 'without transferring them' implicitly routes the agent here when only a total is needed rather than glpi_search or glpi_list_tickets, and it explicitly names glpi_list_search_options for criteria discovery. It stops short of an explicit 'use instead of glpi_search when you don't need the records' statement or any exclusion conditions.

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 it is a non-read-only, non-idempotent, open-world write, so the safety profile is covered. The description adds no behavioral context beyond that: it does not say unknown/unlisted fields are accepted, what validation or error behavior looks like, or that entity/permission scoping applies (assets are created into an entity).

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, purpose front-loaded, no filler. The trailing field enumeration is a dense list rather than prose, which is efficient, though it reads more like a schema restatement than curated guidance.

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?

An output schema exists so return values need not be described. However, for a create operation with a fully open nested payload, the description omits whether additional fields beyond the 'common' list are accepted, whether name is required, and any permission/entity prerequisite — the agent lacks what it needs to invoke this reliably beyond a bare happy path.

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?

Top-level schema coverage is nominally 100%, so the baseline is 3, but the nested 'input' object is `additionalProperties: {}` with only 'Asset fields' as its description. The field list (name, entities_id, serial, locations_id, states_id, ...) is the only real guidance for that open object, which adds value, yet it is flagged as merely 'common' with no indication of which fields are mandatory or how they vary by asset_type.

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 ('Create an asset'), and the asset domain is distinguishable from the many sibling create_* tools (ticket, user, document, entity). It stops short of naming what an 'asset' covers versus those siblings, but the intent is unambiguous.

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, no prerequisites (e.g. required permissions or referenced entity/user IDs needing to exist first), and no pointer to glpi_get_asset / glpi_list_assets / glpi_update_asset as related siblings. The agent must infer all of this.

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=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that — no mention of required permissions, side effects, or whether the change is created in a draft state.

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, front-loaded sentences with no waste. The purpose is stated first and the field hints follow immediately.

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 mutation tool whose input schema is an opaque free-form object, the description is too thin: it doesn't say which fields are required, what defaults apply, or what the created change looks like. The presence of an output schema relieves it of explaining return values, but the input side remains underspecified.

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 schema's single 'input' parameter is a free-form object (additionalProperties: {}) described only as 'Change fields', so it conveys almost no real semantics. The description partially compensates by naming common fields (name, content, entities_id, users_id_requester), which is genuine added value, but it omits required-vs-optional and field formats.

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 clear verb+resource ('Create a new change'), which an agent can distinguish from glpi_create_ticket, glpi_create_problem, and glpi_update_change. It does not, however, differentiate the scope or intent from closely related siblings beyond the resource noun.

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, no prerequisites, and no mention of alternatives such as glpi_update_change or glpi_add_change_followup. The agent must infer usage from the 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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds the meaningful '(metadata)' hint, implying no binary payload, but says nothing about required fields, auth scope, or what happens on failure.

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, purpose front-loaded before the field list, with no filler. The vague 'etc.' slightly dilutes an otherwise efficient structure.

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?

An output schema exists so return values need no explanation, and annotations cover the mutation/safety profile. However, for a create operation on an opaque freeform schema, the description should at least state which fields are required and how this differs from glpi_create_document_item.

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 only parameter is a freeform object with additionalProperties: {}, so the schema itself defines no field names. The description partially compensates by naming name, entities_id, and comment, but the trailing 'etc.' leaves the accepted field set open-ended and unverified.

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 (create a document) and adds the qualifier '(metadata)', which usefully hints that this does not upload binary file content. It stops short of naming or distinguishing itself from the closest sibling, glpi_create_document_item, so an agent must still infer the boundary.

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 statement of when to use this tool versus alternatives such as glpi_create_document_item (linking a document to an item) or the get/list document tools. No prerequisites, permissions, or follow-up steps are given.

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=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the mutation profile is covered. The description adds nothing beyond that: it does not warn that repeated calls create duplicate links (non-idempotent), nor state permission requirements, despite being the natural place to do so.

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 filler, correctly stating verb and operands first. It is efficient, though 'etc.' leaves the accepted itemtype set open rather than bounded.

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?

An output schema exists, so return values need not be explained. However, for a non-idempotent linking mutation with three required parameters, the description omits the lifecycle context (existence prerequisites, duplicate-link behavior) that an agent needs to call it safely, leaving it minimally viable.

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 the schema already documents documents_id, itemtype and items_id, and the description only echoes the itemtype examples ('Ticket, KnowbaseItem'). With the schema doing the heavy lifting, baseline 3 is appropriate; no format, ID-space or type-mismatch guidance is added.

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 ('Create a link') and both resources (document and item), and enumerates example target types (Ticket, KnowbaseItem). It implicitly separates itself from glpi_create_document (creates the document) and glpi_get_document_item/glpi_list_document_items (reads links), but never explicitly routes the agent among those siblings.

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, no stated prerequisites (e.g. that the document must already exist, likely via glpi_create_document, and that the target item must exist), and no mention of the read-side siblings glpi_get_document_item or glpi_list_document_items for verification.

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=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond what the annotations convey—no mention of permission requirements, side effects, or hierarchy constraints. With annotations doing the heavy lifting, a 3 is appropriate.

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 front-loaded sentence followed by a compact field list. Every element earns its place, with no redundant or filler text.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, the description omits usage context such as required permissions, parent-entity validation, or the full set of acceptable fields for a creation tool with a nested, open-ended input object. It is minimally adequate but leaves 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?

The input schema only defines a single open 'input' object with the vague description 'Entity fields'. The description adds real meaning by naming required field name, the parent entity field entities_id with 0=Root semantics, and optional fields comment and address. However, the trailing 'etc.' indicates the list is incomplete, leaving some parameter semantics undisclosed.

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 (Create) and resource (entity), clearly distinguishing it from siblings like glpi_update_entity, glpi_get_entity, and glpi_list_entities. An agent can immediately tell this is a write operation for a new entity.

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 no guidance on when to use this tool versus alternatives such as glpi_update_entity or glpi_create_user. It lists fields but does not state prerequisites, exclusions, or typical scenarios for creating an entity.

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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral beyond that — no permission requirements, no note about template reuse or visibility — it only restates the purpose and lists fields.

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, no filler. Slightly terse but every sentence carries 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?

Output schema and annotations exist, so return values and safety are handled elsewhere. However, for a create tool whose schema hides the real fields behind an opaque object, more detail on field constraints, required vs optional, and template scope would help an agent call it correctly.

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 schema is a loose 'input' object with additionalProperties and 100% coverage of a single opaque parameter, so it does not actually document the nested fields. The description compensates by naming the concrete fields (name, content, comment, itemtype) and giving the allowed itemtype values, which is genuine value 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?

States a specific verb (Create) and resource (followup template), which is clearly distinct from sibling create tools like glpi_create_ticket. It does not explicitly name what separates it from glpi_update_itil_followup_template or list templates, but the purpose is unambiguous.

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 (creating a reusable ITIL followup template) and the itemtype enumeration hints at the Ticket/Change/Problem scoping, but there is no explicit when-to-use, prerequisite, or alternative guidance.

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=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the mutation/safety profile is covered. The description adds nothing beyond that: no mention of required permissions, parent-category constraints, or whether a duplicate name is rejected.

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?

It is a single front-loaded sentence with no padding, which is structurally fine. However, the brevity reflects under-specification rather than disciplined conciseness — there is no second sentence carrying actual value.

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 create tool with a nested free-form input object and hierarchical parent semantics, the description omits everything an agent needs beyond the schema: hierarchy rules, permission expectations, and validation behavior. The output schema and annotations cover the response and safety profile, but the creation semantics are left unexplained.

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?

There is only one parameter ('input'), and schema description coverage is 100% with the nested field list (name, knowbaseitemcategories_id, comment) already documented in the schema. The description adds no parameter meaning of its own, so the baseline 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 restates the tool title almost verbatim ('Create knowledge base category' → 'Create a new knowledge base category'), adding only the word 'new'. It says nothing about the resource's role (GLPI knowledge base hierarchy) and does not distinguish it from adjacent siblings such as glpi_create_knowbase_item or glpi_update_knowbase_category.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. An agent gets no signal about whether to create a category here versus an item, or how this relates to glpi_get_knowbase_category/glpi_update_knowbase_category.

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 declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is defined. The description adds a little about field format ('HTML content') but doesn't cover what happens on creation, validation, or rate limits.

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 then useful field examples. No waste, though the 'etc.' is slightly vague.

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 nested-object create tool with an output schema, the description is thin. It should indicate required fields, whether the category must exist, and basic behavioral expectations. The output schema covers returns, but the input side is under-specified.

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% for the single 'input' parameter, but that parameter is a blanket object with additionalProperties and no field-level documentation. The description lists some fields (name, answer, knowbaseitemcategories_id, etc.) but does not compensate for the lack of schema detail on the nested object.

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?

Specific verb + resource: 'Create a new knowledge base article.' Clearly distinguished from glpi_update_knowbase_item, glpi_get_knowbase_item, and glpi_create_knowbase_category among the sibling tools.

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 glpi_update_knowbase_item or glpi_create_knowbase_category. No context about required permissions or prerequisites.

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=false, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the mutation and safety profile is covered. The description adds nothing beyond that: no mention of required permissions, whether duplicate problems are rejected, or what the operation returns.

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 the purpose front-loaded and field hints second. Tight and efficient, though the field list is a bare enumeration with no indication of which fields are required.

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?

An output schema exists, so return values need not be explained. For a create tool whose input is an unconstrained object, however, the description gives only four sample fields and no required/optional distinction, leaving the agent under-specified on the actual payload.

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 schema exposes only a free-form "input" object (additionalProperties: {}), so the enumerated fields (name, content, entities_id, users_id_requester) provide real semantic value that the schema does not. It falls short of a full field list or required-field indication, hence not a 5.

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 ("Create a new problem"), which is unambiguous on its own. However, it offers no differentiation from the many sibling create tools (glpi_create_ticket, glpi_create_change, glpi_create_asset), leaving the agent to infer from the name alone when a problem is the right ITIL object.

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, no prerequisite information, and no mention of alternatives such as creating a ticket or change. Nothing tells the agent under what circumstances a problem record should be created rather than another ITIL type.

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=false, idempotentHint=false and destructiveHint=false, so the mutation profile is covered structurally. The description adds the trap that reservationitems_id is not the asset ID, but says nothing about permission needs, how booking conflicts are handled, or whether a failed window is rejected.

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 short sentences, front-loaded with the action, then the two highest-risk parameter facts. Tight and readable, though the date-format sentence partially duplicates the schema.

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 an output schema present, return values need not be described, and the description covers the two most error-prone inputs. It leaves users_id semantics and any conflict behavior unstated, but that is a modest gap for a 5-param tool with full schema coverage.

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 both begin/end already carry the 'YYYY-MM-DD HH:MM:SS' format in their schema descriptions, so the format sentence largely restates structured data. The genuinely additive piece is '(not the asset ID)', which prevents a common misuse of reservationitems_id; 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?

'Book a reservable item' gives a specific verb (book/create) and resource (reservable item), clearly distinct from the get/list reservation siblings. It does not explicitly distinguish itself from glpi_update_reservation, but the create vs. modify intent is unambiguous.

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 points the agent to glpi_list_reservation_items as the source of the required ID, which is a useful workflow hint. However, it never states when to use this versus glpi_update_reservation, nor any prerequisites (permissions, conflict-free window) beyond the ID lookup.

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=false, idempotentHint=false and destructiveHint=false, so the write semantics are covered structurally. The description adds the action_type vocabulary (assign/regex_result/append_regex_result), which is genuinely useful behavior context since the schema leaves the nested object untyped, but it says nothing about permissions required or side effects on existing rules.

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, front-loaded with the operation and followed by the field list; nothing is padded. It is terse to the point that some items (meaning of 'field', target rule type) go unaddressed, but there is no wasted text.

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?

An output schema exists, so return values need not be explained, and annotations cover the mutation profile. However, for a write tool in a family with both generic rules and rule_ticket variants, the description never clarifies which rule set rules_id refers to or what auth/scope is needed, leaving a meaningful ambiguity for an agent choosing among siblings.

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 only top-level parameter is a free-form 'input' object whose nested keys are the real payload. The description enumerates those keys (rules_id, action_type, field, value) and supplies the only enum-like vocabulary for action_type, which the schema does not provide. This compensates well for the schema's untyped additionalProperties, though the meaning of 'field' and 'value' is left unexplained.

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+resource ('Create a new action for a rule') and enumerates the fields involved, so the agent knows exactly what object is being created. It does not, however, distinguish this generic rule-action creator from the closely named siblings glpi_create_rule_criteria, glpi_create_rule_ticket or glpi_update_rule_action.

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 or when-not-to-use guidance, no prerequisites, and no pointer to alternatives such as glpi_create_rule_criteria or glpi_update_rule_action. The agent must infer that this is the write-side companion to glpi_list_rule_actions purely from the name.

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=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds no behavioral context beyond that — no mention of effects on existing rule evaluation, required permissions, or creation semantics. With annotations carrying the load, a 3 is the appropriate minimum-viable score.

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 compact sentences with the core action front-loaded and the field list appended. No filler, though the field enumeration partially duplicates the schema description.

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 create tool whose safety profile is covered by annotations and which has an output schema, the description is minimally adequate. It nonetheless leaves gaps an agent would want: valid condition operators/values, and how criteria field names map to GLPI search options.

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 schema's top-level 'input' object has additionalProperties={}, so inner fields are effectively undocumented by structure; the description's list of fields (rules_id, criteria, condition, pattern) is the main source of meaning. It still omits the accepted values for 'condition' or where 'criteria' field names come from (search options), so it does not fully compensate for the free-form nested object.

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 ('Create a new criteria for a rule'), which is inherently distinguishable from siblings like glpi_create_rule_action or glpi_create_rule_ticket. However, it never names or contrasts those siblings, and 'criteria' vs 'action' vs 'rule' selection is left to the agent's 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 offers no when-to-use guidance, no prerequisites (e.g., that the parent rule must already exist), and no mention of alternative tools such as glpi_create_rule_action or glpi_update_rule_action. Usage is only implicit in the name.

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=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds nothing behavioral beyond that — no note on permissions required, no statement of what happens to existing or triggering rules, and no indication that the created rule takes effect on new tickets.

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 the action front-loaded and no filler. The truncated field list ending in 'etc.' is the one element that wastes rather than earns space, since it signals incompleteness without resolving it.

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?

An output schema exists so return values need not be explained. However, for a rule-creation tool whose entire input is an opaque free-form object, the definition should at minimum outline required fields, the AND/OR semantics of 'match', and the relationship to the criteria/action creation tools. It is minimally viable but 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?

The schema only exposes a free-form 'input' object with additionalProperties={} and the description 'Rule fields', so it provides almost no real field documentation. The description compensates by naming concrete fields — name, match (AND/OR), is_active, sub_type, ranking — which is genuinely new information. It loses a point for trailing off into 'etc.' and leaving required vs optional fields unspecified.

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+resource: 'Create a new ticket business rule', which is distinguishable from glpi_create_rule_action and glpi_create_rule_criteria (sub-resources of a rule) and from glpi_get_rule_ticket / glpi_list_rules. It does not, however, explicitly name those siblings or clarify how the ticket rule relates to its criteria/actions, so it stops short of full differentiation.

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, no prerequisites (e.g., admin rights), and no mention of alternatives or the workflow of attaching criteria/actions afterward. The agent must infer the usage context entirely from the name.

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=false, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that – no note on the risk of duplicate tickets given non-idempotency, no permission/auth requirements, and no side effects such as notifications to requesters.

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 front-loaded sentences with no filler; the purpose comes first and the field list follows. The list is dense but each item is useful given the empty schema, so little could be cut without losing 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?

An output schema exists, so return values are not the description's burden. However, for a creation tool with a completely open input object, the description doesn't state minimum required fields or the duplicate-creation caveat implied by idempotentHint=false, leaving gaps an agent would need filled.

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 is effectively unconstrained (a single free-form object with additionalProperties: {}), so the description is the only real source of field semantics and it delivers: it maps common field names to meaning and decodes the type enum (1=Incident, 2=Request). It falls short of stating which fields are required or the full field set.

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+resource ('Create a new ticket') and backs it with a concrete field list, which cleanly separates it from glpi_update_ticket, glpi_get_ticket, and glpi_list_tickets. It does not, however, explicitly name a sibling or scope boundary (e.g., ticket vs change vs problem).

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 alternatives named. Given siblings like glpi_create_change and glpi_create_problem exist, an agent gets no signal about when a ticket is the right artifact versus those. Usage is only implied by the verb.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the mutation/non-destructive/non-idempotent profile is covered. The description adds the useful framing that this creates an approval request tied to a validator, but omits side effects such as notifications to the approver or duplicate-validation 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?

A single front-loaded sentence with no filler; the parenthetical naming users_id_validate is slightly redundant with the schema but harmless. Efficient overall.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, for a mutation tool with several close siblings, the description lacks the routing and prerequisite context an agent needs to select it confidently.

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 all three parameters (ticketId, users_id_validate, comment_submission) are already documented in the schema. The description only echoes users_id_validate and adds no format, constraint, or semantic detail beyond the schema, matching the baseline 3.

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 uses a specific verb ('Create') and clarifies the domain meaning of a 'ticket validation' as an 'approval request assigning a validator', which is more than a restatement of the name. It does not, however, distinguish this tool from close siblings like glpi_update_ticket_validation or glpi_create_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?

There is no guidance on when to use this tool versus alternatives such as glpi_update_ticket_validation or glpi_list_ticket_validations, nor any stated prerequisite (e.g. ticket must exist, validator must be a valid user). Usage must be inferred entirely.

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=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds nothing beyond the user fields, but with annotations covering the safety profile and the schema documenting the structure, the description doesn't contradict and doesn't need to repeat. It adds marginal value by naming common fields, but doesn't mention permissions, duplicate-login behavior, or password policy.

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 tight sentences, front-loaded with the action and required field. Zero waste.

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 is a create mutation with openWorld and no idempotency. The description names common fields but omits duplicate-user behavior, required permissions, and validation semantics. With annotations covering safety and an output schema present, the description is adequate but leaves behavioral gaps for an agent creating a real user.

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% with the nested input object described as 'User fields'. The description adds field names (name, realname, firstname, password, email via _useremails) which is useful context beyond the opaque schema, but the schema itself is flexible (additionalProperties: {}) so the description is doing important work naming the key fields. However, it doesn't explain the _useremails array structure or required constraints beyond 'name (login)'.

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 (Create) and resource (GLPI user), clearly distinguishing it from glpi_update_user and glpi_get_user siblings. Lacks explicit differentiation phrasing but the operation is unambiguous.

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 vs glpi_update_user or glpi_search_user_by_email, no prerequisites, no mention of what happens if the login already exists. The agent is left to infer usage context entirely.

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=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the write/open-world nature is covered. The description adds the field vocabulary of a webhook but does not disclose auth requirements, side effects, or whether creation triggers delivery attempts beyond what the 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?

Two sentences, no filler, with the core action front-loaded and the field list kept to a compact inline enumeration. Every clause carries 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The gap is that an agent is not told which fields are required to create a valid webhook, given the open-ended input object, leaving a meaningful operational unknown.

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 declared schema is an opaque object (additionalProperties: {}, only 'Webhook fields'), so the description's enumeration of name, url, itemtype, event, is_active, payload, http_method, use_cra_challenge is the only real field documentation, with useful examples for itemtype and event. However it is framed as 'common fields' with no required/optional distinction or formats, so it compensates only partially. Baseline 3 given the nominal 100% coverage.

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 (create) and resource (webhook), which cleanly separates it from siblings like glpi_update_webhook, glpi_get_webhook, and glpi_set_webhook_active. It does not explicitly name those siblings, but the name+title make the purpose unambiguous.

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, no mention of prerequisites, permissions, or when not to create a webhook. It simply restates the action, leaving all routing decisions 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description's only added behavioral content is the scope statement that this returns exactly one asset, which is minor; it says nothing about permissions, missing-ID behavior, or output shape (though an output schema exists).

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 the core purpose front-loaded and the disambiguation trailing. No filler, no repetition of the title.

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 rich annotations, a fully described five-parameter schema and an output schema present, the description only needs to establish purpose and routing, which it does. It is complete for correct invocation, though a note on asset_type/assetId pairing errors or when to use glpi_list_assets would close the remaining gap.

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 three of five parameters have enums, so the schema fully documents asset_type, assetId, fields, format and expand_dropdowns. The description adds no syntax or format guidance beyond what the schema already provides, making the baseline 3 correct.

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 ('Retrieve a single asset by type and ID') and explicitly names the sibling it is not (glpi_get_asset_details for hardware detail). An agent can distinguish it from glpi_get_asset_details and glpi_list_assets without opening a 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_asset_details when hardware detail is needed, which is a real disambiguation against a very similarly named sibling. It does not, however, mention when to prefer glpi_list_assets for multiple items or state any prerequisites/permissions.

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 behavior. The description adds meaningful context beyond them: hardware defaults, names-instead-of-IDs, and that softwares/networkports are large on inventoried hosts and only returned when requested. It stops short of describing pagination/truncation behavior beyond the schema's max_items_per_section.

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-loads the core purpose, then adds the default fields, the large-section caveat, and the sibling alternative in tight, waste-free prose.

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?

Output schema exists, and annotations cover safety, so the description needn't explain returns. It covers the key behavioral caveats (default vs opt-in sections) needed to call correctly; minor gap is not restating truncation reporting, though the schema's max_items_per_section covers 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 100%, so baseline is 3. The description adds value by clarifying that sections defaults to hardware fields and that softwares/networkports must be explicitly listed, which refines the schema's flat section list. It leaves fields/format/max_items_per_section to 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?

States a specific verb and resource ('Get one GLPI asset ... together with its hardware details in a single call') and explicitly delineates the asset types and returned hardware fields. It also distinguishes itself from the sibling glpi_get_asset by naming it as the plain-record alternative.

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?

Tells the agent to use glpi_get_asset for the plain asset record and this tool for hardware details, and explains that softwares/networkports must be requested via sections. It does not cover when asset_type choices beyond the enumerated ones apply, but the routing guidance is explicit.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds genuine output behavior the annotations do not: dropdown IDs are resolved to names and status/priority values are localized to the GLPI user's language.

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 filler; the core action comes first and the output-shaping detail follows. Nothing here is wasted.

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 an output schema present, the description is not obligated to explain return values, and it correctly focuses on scope and output shaping instead. For a simple four-parameter read tool this is nearly sufficient, with only the when-to-use guidance left 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 description coverage is 100%, so all four parameters are already documented in the schema and a baseline of 3 applies. The description echoes changeId ('by ID') and hints at name expansion, which maps loosely to expand_dropdowns and fields, but adds no new syntax or defaults.

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 gives a specific verb (Retrieve) and resource (a change), and the 'by ID' qualifier separates it from glpi_list_changes without needing a schema read. It never names the sibling alternatives explicitly, so it falls short of the top band.

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 only implied: fetching a single change by its identifier as opposed to listing changes. There is no statement about when to prefer this over glpi_list_changes or glpi_search, and no prerequisites such as read permissions on the item.

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 fully covered structurally. The description adds nothing beyond that — no note on what a document contains, whether access is permission-gated, or any rate/scope caveat. With annotations carrying the load, a low score reflects the absence of any supplementary behavioral context.

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 no filler, and the key identifier ('by ID') is front-loaded. It is efficient, though the brevity edges toward under-specification rather than true concision.

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?

An output schema exists so return values need not be described, and annotations cover the safety profile, making the minimal description roughly viable for a simple by-ID lookup. Still, nothing tells the agent how this differs from related document tools or what access assumptions apply.

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 two of the three parameters are enums with inline explanations, so the schema fully documents inputs. The description contributes no additional meaning about documentId, fields, or format, which is exactly the baseline-3 case.

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 ('Retrieve a document by ID'), which is unambiguous as an operation. However, it does not differentiate from close siblings such as glpi_get_document_item (the link between a document and an item) or glpi_list_documents, leaving the agent to infer the boundary.

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, even though glpi_list_documents and glpi_get_document_item are adjacent candidates an agent could confuse with this one. The description simply restates the operation without routing the agent.

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=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note on permissions, result scope, or what a 'link' record contains — so it earns no credit for behavioral disclosure.

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 zero filler or redundancy. It is efficient, though the economy comes at the cost of the guidance the tool lacks rather than through disciplined editing of richer content.

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 is simple (single required ID), annotations carry the full safety profile, the schema is 100% documented, and an output schema exists so return values need not be described. The only real gap is lack of sibling routing, which is minor at this complexity.

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%, with both enums (fields, format) and documentItemId fully documented in the schema itself. The description adds no meaning beyond the schema, so the baseline 3 applies rather than a penalty.

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+resource ("Retrieve a Document_Item link") plus the keying parameter ("by ID"), so the operation is unambiguous. However, it does nothing to distinguish this "link" entity from siblings like glpi_get_document or glpi_list_document_items, leaving the agent to infer what a Document_Item link is.

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, no prerequisites, and no reference to any alternative such as glpi_list_document_items or glpi_get_document. The agent is left to infer selection context purely from the tool name.

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=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond the title — no note on GLPI entity hierarchy, permission/visibility scoping (entities are access-controlled in GLPI), or what 'retrieve' returns at a high level. With the annotation bar already met, the description contributes no extra behavioral context.

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 zero filler or repetition. It is efficient, though its brevity is also the source of the gaps elsewhere rather than a deliberate trade-off.

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?

Output schema exists, so return-value explanation is not required, and annotations cover the safety profile. What is missing is the surrounding context an agent needs to choose this tool — when an entity ID is warranted over listing or over glpi_get_my_entities — leaving the definition merely 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 description coverage is 100%, and both optional enums ('fields', 'format') are documented in-schema with their defaults and semantics. The description adds nothing about parameters, so it cannot exceed the baseline; a 3 is the correct floor when the schema fully carries the parameter burden.

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 ('Retrieve an entity by ID'), which cleanly separates it from the listing sibling glpi_list_entities. However, it never names or contrasts against the similar one-off readers glpi_get_my_entities or glpi_get_asset, so the agent gets no explicit sibling differentiation beyond the ID hint.

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 statement of when to use this tool versus glpi_list_entities (browse/filter) or glpi_get_my_entities (current user scope). No prerequisites, no note that entityId must be known in advance, no exclusions. The agent must infer usage entirely from the name.

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 fully covered without description help. The description adds only scope-of-returned-data (entity/profile/user), and says nothing about auth requirements or what happens if no session exists. Adequate, not rich.

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 tight sentences that front-load the what before the why, with no filler. The second sentence is arguably redundant given the tool name, but it carries the only usage signal present.

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?

An output schema exists, so return-value structure need not be explained, and the description still summarizes the payload's content (entity, profile, user). For a zero-required-parameter read-only tool with rich annotations, an agent has everything needed to invoke it correctly.

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% with two enum-constrained, optional parameters ('fields' and 'format'), both fully documented in the schema. The description adds no parameter meaning beyond it, so the baseline 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?

States a specific verb and resource ('Get the full session info') and enumerates what the payload contains: active entity, profile, and user details. This makes it distinguishable in spirit from glpi_get_my_entities and glpi_get_my_profiles, though it never names those siblings as alternatives or clarifies the overlap.

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?

'Useful for debugging and verifying the current session context' gives a genuine, concrete use case rather than leaving usage implied. It stops short of exclusions or alternatives ('use X instead when...'), so it lands at clear-context-but-no-routing.

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=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.

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.

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.

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.

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.

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.

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 nothing beyond that — no note on error behavior for a missing ID, no mention of permission requirements, and no return-shape context.

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 six-word sentence with the verb front-loaded and zero waste. It is efficient, though bordering on under-specification rather than genuine conciseness.

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 is a simple single-item getter with a full output schema and annotations, so return values and safety need not be restated. However, with ~100 sibling tools, the missing routing signal between get and list leaves a real gap for correct tool selection.

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 the schema documents fields, format, and the ID (including its accepted integer/string forms). The description's 'by ID' adds no meaning beyond the schema, so the baseline 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?

States a specific verb (Retrieve) and resource (ITIL category) scoped to a single item by ID, which implicitly separates it from the list variant. It does not name glpi_list_itil_categories as the sibling alternative, so differentiation is left partly to 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?

No explicit guidance on when to use this versus glpi_list_itil_categories or glpi_search. The ID-based phrasing implies 'use when you already have the identifier,' but this is never stated, and no prerequisites are given.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered elsewhere. The description adds no behavioral context of its own (no note on what happens with an invalid/unknown ID, permissions, or output shape), so it contributes essentially nothing beyond structured fields.

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 no filler, front-loading the operation and the key identifier. It is efficient, though its brevity is also why it leaves gaps the other dimensions penalize.

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?

An output schema exists, so return values need not be explained, and annotations plus 100% schema coverage handle safety and parameters. What remains missing is routing context against the list/update/create siblings, leaving the definition minimally adequate rather than 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%, with clear enum descriptions for 'fields' and 'format' and a documented 'expand_dropdowns' flag, so the schema carries parameter semantics. The description mentions only the ID and adds no meaning beyond it, which fits the baseline 3 when the schema does the heavy lifting.

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 clear verb ('Retrieve'), resource ('followup template'), and access method ('by ID'), which an agent can act on directly. It does not distinguish itself from glpi_list_itil_followup_templates, so the agent must infer that this is the single-item lookup versus the listing.

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 when-to-use guidance and no mention of the sibling alternatives (glpi_list_itil_followup_templates, glpi_update_itil_followup_template, glpi_create_itil_followup_template). The 'by ID' phrasing implies the precondition of needing an ID, but that is the only usage cue.

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 fully covered. The description adds no behavioral context of its own — no error behavior for a missing ID, no note on what a non-existent category returns — so it contributes nothing beyond the structured data.

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 the resource and lookup key first and zero filler. Nothing could be removed without losing 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?

For a simple read-by-ID tool with full annotations, a fully described parameter schema and an output schema handling return values, the description is close to sufficient. The only shortfall is that it does not mention the fields/format options or disambiguate from the sibling list and item tools, but the agent has enough to call it correctly.

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 categoryId, the 'essential'/'all' fields enum and the json/markdown format enum are all documented in the schema itself. The description mentions none of them and adds no syntax or format meaning beyond what is already there, making 3 the correct baseline.

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 (retrieve) and resource (knowledge base category) plus the lookup key (by ID), which cleanly separates it from glpi_list_knowbase_categories and glpi_get_knowbase_item. It stops short of naming those siblings explicitly, so the differentiation must be inferred from the tool names.

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 or when-not-to-use guidance. 'By ID' weakly implies the caller must already know the identifier, but nothing tells the agent to call the list tool first or how this differs from glpi_get_knowbase_item.

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 fully covered without the description. The description adds nothing beyond that — no note on authentication, error behavior for a missing ID, or whether the item is fetched from an external/open corpus.

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 zero padding. It is efficient, though its brevity is close to under-specification rather than deliberate conciseness.

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?

An output schema exists and the input schema fully documents all three parameters, so the description need not cover return values. For a simple get-by-ID tool this is minimally adequate, but it offers no behavioral context to help the agent call it correctly in ambiguous situations.

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 the schema documents knowbaseId plus the fields/format enums in detail, so the baseline of 3 applies. The description adds no semantics beyond 'by 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?

States a specific verb ('Retrieve') and resource ('knowledge base article') scoped by ID, which clearly separates it from glpi_list_knowbase_items and glpi_update_knowbase_item. It does not explicitly name a sibling, so routing relies on the agent inferring the singular/by-ID 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 guidance on when to use this versus glpi_list_knowbase_items, glpi_search, or glpi_get_knowbase_category. The only implicit signal is 'by ID', which the agent must interpret on its own.

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 adds little beyond the operation itself — no mention of auth requirements, error behavior for missing IDs, or output characteristics.

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 zero waste. Nothing redundant, and the operation is stated up front.

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?

An output schema exists and annotations cover the safety profile, so the description needn't explain return values. Still, for a getter tool the description could have noted missing-ID behavior or the essential-vs-all field tradeoff; as-is it is minimally 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 description coverage is 100%, so all three parameters (locationId, fields, format) are already documented in the schema. The description only implies the ID parameter and adds no syntax or enum guidance beyond what the schema provides; baseline 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 ('Retrieve a location by ID'), which is clear enough to distinguish a single-item getter from the listing sibling glpi_list_locations. It doesn't explicitly name that sibling, so it falls short of full sibling differentiation.

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 'by ID' phrasing implies it is for single-item lookup, which hints at when to use it, but there is no explicit statement about when to use this versus glpi_list_locations or other alternatives.

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 fully covered by structured data. The description adds only the access-scoping notion ('available to the current user'), which is genuinely useful, but nothing about return shape or permission behavior beyond that.

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 sentence, front-loaded with the verb and resource, with the scoping qualifier in the right place. No filler, no repetition of the title.

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 zero-required-param read tool with an output schema and rich annotations, the description covers the essential purpose and scope. It would be complete with one line routing the agent between this, glpi_list_entities, and glpi_change_active_entities.

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% with both optional params (fields, format) fully described including enum values, so the schema does the heavy lifting. The description adds nothing about the parameters, which is the expected baseline at full coverage.

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 ('Get') and resource ('entities') with the scope qualifier 'available to the current user', which contrasts with the sibling glpi_list_entities (all entities) and glpi_get_entity (single entity). Clear, though it never names those siblings explicitly.

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 gives no when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is the scoped-down variant of glpi_list_entities and that glpi_change_active_entities is the related write operation, with no help from the text.

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 fully covered by structured data. The description adds the useful current-user scoping but says nothing about auth prerequisites or what the profile list contains. With annotations carrying the operational profile, a 3 is appropriate.

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 zero waste. It is arguably too terse, but every word earns its place and the key scope qualifier is not buried.

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?

A simple read tool with rich annotations, 100% parameter documentation and an output schema, so return values need not be explained in prose. The only remaining gap is the absence of any when-to-use routing against similar session/profile tools.

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 both parameters (fields, format) are fully documented with enum semantics, so the schema does the heavy lifting. The description adds no further detail on the fields/format behavior, which is fine at baseline.

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 ('Get the list of profiles') and scopes it to 'the current user', which distinguishes it from the many glpi_list_users / glpi_get_user siblings that operate on arbitrary users. It does not explicitly name an alternative, but the scope is unambiguous.

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 only implied by the phrase 'available to the current user'; there is no statement of when to call this versus glpi_get_my_entities, glpi_get_full_session, or glpi_list_users. The context is clear enough for a simple read tool, but no exclusions or alternatives are offered.

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, openWorld, so safety is covered. The description adds genuine context about output behavior (dropdown names rendered beside IDs, localized labels in the GLPI user's language), but does not address the interaction with the expand_dropdowns/fields options or error behavior for a missing 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 filler; the resource, access key, and output enrichment are all stated up front.

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?

Output schema exists and annotations carry the safety profile, so return value and permission details are not needed in prose. For a read-only single-item fetch, the description supplies everything required to invoke it correctly.

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% with two enum parameters fully documented in the schema, so the baseline is 3. The description adds no parameter-level detail (e.g., how 'fields' interacts with name expansion or what 'format' affects for a single item) beyond what the schema already states.

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 ('Retrieve a problem by ID') and describes the output enrichment (names beside IDs, localized status/priority labels). It implicitly distinguishes itself from glpi_list_problems by the 'by ID' framing, but never names the list/search siblings explicitly.

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 'by ID' phrasing implies this is the single-item fetch versus the list/search alternatives, so usage is inferable. However, there is no explicit when-to-use statement, no mention of prerequisites, and no routing to glpi_list_problems or glpi_search for other access patterns.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is well covered. The description adds no behavioral context beyond 'Retrieve', such as authentication requirements, pagination behavior, or anything about how missing IDs are handled.

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 filler. It is appropriately sized for a simple retrieval tool and every word earns its place.

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 is simple, the input schema is fully documented, an output schema exists, and annotations cover the safety profile, so the description is arguably sufficient for calling it. However, it does not clarify when to use this tool versus glpi_list_reservations or how the optional fields and format parameters affect the retrieval 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?

Schema description coverage is 100%, and the schema itself documents reservationId, fields, and format in detail. The description adds no parameter meaning beyond the schema, so the 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?

States a specific verb (Retrieve) and resource (reservation) with a scoping qualifier (by ID), which distinguishes it from list/create/update siblings. However, it does not explicitly name or contrast itself with glpi_list_reservations or other get tools, so it stops short of full sibling differentiation.

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 gives no when-to-use guidance, no exclusions, and no alternative tools for retrieving reservation information. The 'by ID' qualifier implies lookup usage, but no condition or alternative selection is stated.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered elsewhere. The description adds nothing beyond that – no note on whether the rule is fetched live, what happens for unknown/invalid IDs, or any permission/auth context.

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 the purpose and the key lookup key ('by ID') first; no filler or redundancy. It is appropriately sized, though extremely terse, leaving room that guidance could have used.

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?

An output schema and full annotations exist, so return values and safety need not be repeated. For a simple single-item getter the description is minimally sufficient, but it omits when-to-use routing against the rule-related siblings, which is the one thing structured fields cannot supply.

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 fields, format, ruleId and expand_dropdowns are already documented in the schema with enums and patterns. The description mentions only 'by ID' and adds no semantics beyond the schema, so the baseline 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?

States a specific verb and resource ('Retrieve a ticket business rule (RuleTicket) by ID'), naming the GLPI entity so an agent knows what object is returned. It does not, however, distinguish itself from nearby siblings such as glpi_list_rules or glpi_list_rule_ticket_criteria other than by implying single-item retrieval.

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 only usage cue is 'by ID', with no statement of when to use this versus the rule-listing tools or the criteria/action siblings. There are no prerequisites, exclusions, or alternatives named, so the routing decision is left entirely 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, non-destructive, openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: dropdown IDs come with names beside them, and names are rendered in the GLPI user's language, which affects how results should be read.

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 tight sentences, front-loaded with the core action, followed by field-shape context and the routing note. No filler, and the most important information comes first.

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 an output schema present, the description need not explain return values, and it still closes the main gap an agent would hit: where to find ticket users and groups. Nothing needed to invoke or interpret this read-only tool 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 description coverage is 100%, so the baseline is 3. The description goes slightly further by enumerating the name fields that appear alongside IDs (recipient_name, category_name, entity_name, status_name, type_name, priority_name), which clarifies the default non-expanded behavior and the trade-off behind expand_dropdowns.

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 with explicit scope: retrieve a single ticket by ID. It is immediately distinguishable from the many list/create/update ticket siblings, and the singular 'single ticket by ID' rules out the listing tools.

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?

Gives clear 'when not' guidance by naming glpi_list_ticket_users and glpi_list_ticket_groups as the tools for requesters/technicians/observers/groups, which are not ticket fields. It does not explicitly contrast with glpi_list_tickets or glpi_search, but the alternative routing for related data is concrete.

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 cover readOnly, idempotent, destructive=false and openWorld, so the safety profile is fully declared. The description adds genuine behavioral context beyond that: the result is aggregated counts, no ticket records are returned, and criteria are optional. It does not discuss pagination or scale limits, but for an aggregate read those gaps are minor.

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 compact two-part sentence that front-loads the payload (per-status counts + total) and then the optional narrowing mechanism. The embedded inline example makes the second half dense, but every element earns its place.

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 optional parameter, full schema coverage, an output schema and safety annotations, the description supplies everything needed to invoke it correctly, including the non-obvious search-option field IDs. The example criteria omits the 'link' element and the option-ID list is illustrative rather than exhaustive, which keeps it just short of fully 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 already 100%, yet the description still adds real meaning by supplying concrete Ticket search option IDs (80=entity, 4=requester, 5=technician, 7=category) that appear nowhere in the schema, plus a worked criteria example and a pointer to glpi_search for the same shape.

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+resource+output shape: counts of tickets broken down by the five named statuses plus a total. The clause 'without listing the tickets' explicitly distinguishes it from the many sibling list tools (glpi_list_tickets, glpi_list_my_tickets), so an agent can tell them apart without opening schemas.

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?

Makes clear this is the tool for aggregate counts rather than enumeration, and shows how to narrow scope with a concrete entity example. It also points at glpi_search for the criteria shape, which helps reuse. It stops short of naming an explicit alternative or a when-not condition beyond the implicit 'not listing' contrast.

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=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that—no note on what happens when the ID does not exist, no permission context, no mention of the fields/format output knobs. A terse lookup tool needs little, but zero added context is still zero.

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?

One short sentence with zero filler and the key lookup parameter front-loaded. It is genuinely concise rather than merely under-specified, though the terseness leaves no room for routing or behavioral content.

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 is low complexity, has an output schema, 100% schema coverage, and rich annotations, so most structured information is already available to the agent. What remains missing is the routing signal against near-neighbor read tools and any hint about failure behavior for an unknown ID.

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%: userId, fields, and format are all documented in the schema, including enum meanings for 'essential'/'all' and 'json'/'markdown'. The description's 'by ID' merely restates the required userId parameter and adds no syntax or format detail beyond the schema, so the baseline 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?