query_info

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real operational context the annotations lack: default limit 50 with a 200 cap, 0-based round with latest-by-default, and that profiles may surface not-installed or placeholder agents. It doesn't describe result shape or what happens when no matching task exists. Given the annotations do the safety work, this lands at a solid 3.

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 discriminator stated first and the three modes in order, so scanning maps cleanly onto the enum. It is dense — nested parentheses within parentheses for the per-mode details — which costs some readability but almost 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?

For a 6-parameter, three-mode tool with no output schema and zero schema description coverage, the description covers the dispatch logic, defaults, and mode-specific requirements well. The remaining shortfall is the undocumented `status` value set and no statement of what the tasks listing contains per row.

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 must carry the semantics, and it largely does: it explains the `type` enum values, `limit` default and cap, `round` base and default, and which parameters apply to which mode. The gap is `status`, whose accepted values are never stated in either the schema or the description, so the agent must guess valid filter strings.

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 purpose: a single unified query entry point that merges three named predecessors and dispatches on a `type` discriminator with three fully enumerated modes (tasks/report/profiles). An agent can tell what each mode returns. It does not, however, distinguish itself from the live sibling `query_task`, so the boundary with that tool remains inferential.

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 spelled out per mode: `taskId` is mandatory for type=report, `round` defaults to the latest round, tasks can be filtered by `projectPath`/`status`. That is clear when-to-use guidance. There are no explicit when-not conditions and no routing advice versus `query_task`, which keeps it below a 5.

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