glpi_get_asset_stats

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

No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether the operation is read-only, what the output structure looks like, whether it requires specific permissions, or any caveats (e.g., performance implications, data ranges). The description is generic and does not add behavioral context beyond the simple 'returns stats'. This is insufficient for a tool that aggregates 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?

The description is very concise: one sentence. It is front-loaded and to the point. No fluff. However, it is somewhat sparse for a tool with multiple parameters and potential complexity. It earns a 4 because it is efficient, though it could benefit from a tiny bit more detail while maintaining 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?

Given the tool has 3 parameters, no annotations, no output schema, and no explanation of return values, the description is incomplete. It does not mention the output format, whether the stats are counts, sums, or other metrics. It also doesn't explain how date ranges interact or what 'associated assets' means precisely. For a tool that computes stats, more context is needed about what data is returned and any limitations. Because of the lack of annotations and output schema, the description should carry more weight and it doesn't.

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%: all parameters have descriptions. The 'itemtype' is an enum with allowed values, and date_start/date_end are described as dates with format. The description adds no new parameter semantics beyond the schema, but since coverage is high, the baseline is 3. The description does not explain the relationship between parameters (e.g., date_start/date_end are optional and define a range) but the schema already conveys that. Since the tool name suggests 'stats', the parameters are adequately specified. A score of 4 is justified because the schema descriptions are precise and complete.

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 it returns statistics of assets associated with tickets, changes, or problems, which is a clear verb+resource. However, it doesn't distinguish from siblings like glpi_get_ticket_stats, glpi_get_problem_stats, or glpi_get_change_stats, which likely also compute stats. The name 'glpi_get_asset_stats' suggests it's focused on assets, but the description lacks specifics on what exactly the stats include. It's clear but not differentiated from similar stats 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. For instance, when one needs asset stats vs. ticket stats or problem stats. The description doesn't state any conditions, limitations, or context for use. It only says the tool returns stats, but not when to choose it over sibling stats tools. Given multiple sibling tools with similar names and purposes, the lack of guidance is a notable gap.

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