call_read

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description only needs to add context beyond that. The phrase 'GET any All Quiet API operation' conveys the tool's generic pass-through nature. It does not disclose error handling or auth requirements, but given annotation coverage, the added context is acceptable.

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

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

Two short sentences with no redundant filler. The core purpose is front-loaded, and the workflow instruction is concise.

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 generic read proxy, the description plus schema covers the essentials: what to provide (path/query/path_params) and how to discover operations. Since there is no output schema, exact return depends on the specific All Quiet operation, which is implied by 'any operation' and openWorldHint. This is adequate, though it could mention that the response format varies.

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 detailed descriptions for path, query, and path_params including examples like '/team/{id}' and repeated key syntax. The description itself adds no parameter-specific information, but the schema fully documents the parameters, 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?

Description states a specific verb 'GET' and a resource 'any All Quiet API operation', clearly distinguishing this read tool from call_write and call_delete. The reference to list_operations further clarifies its role as a generic dispatcher.

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 instruction 'Find it first with list_operations' gives an explicit workflow for when to use this tool. It implies that call_read is for read-only GET operations, but does not explicitly state when not to use it or name call_write/call_delete as alternatives.

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