List mirrored LandIS archive items with their triage classifications to identify data availability and status.
List locally mirrored LandIS archive items and their triage classification.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| tool | No | ||
| limit | No | ||
| family | No | ||
| offset | No | ||
| surfacingClass | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.8.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe, read-only nature is covered. The description adds useful context by clarifying that items are locally mirrored and that triage classification is part of the result, but it does not disclose pagination behavior, filter semantics, or output size 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?
The description is a single, front-loaded sentence with no filler words. It states the core action and the notable output attribute efficiently. However, the brevity borders on under-specification, which costs it the top score.
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 tool with six parameters, no schema descriptions, and no usage guidance, the description is too thin. It does not explain what distinguishes archive items, what triage classification means, how to narrow results, or how this relates to landis_archive_get_item. The output schema helps, but the agent still lacks enough context to call the tool 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 0%, so the description carries the full burden of explaining six parameters: q, tool, limit, family, offset, and surfacingClass. The description only mentions listing archive items and triage classification; it does not explain what any parameter means, how filters interact, or how pagination works.
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 ('List'), a specific resource ('locally mirrored LandIS archive items'), and adds the distinguishing detail that triage classification is included. This differentiates it from related siblings like landis_archive_get_item (single item retrieval) and landis_catalog_list_products (catalog products, not archive items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives. 'Locally mirrored' and 'archive items' imply a scope, but there are no stated exclusions, prerequisites, or references to sibling tools such as landis_archive_get_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.