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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds context those cannot convey: a result cap (default 50, max 200), the need to check the 'truncated' flag, and the required read scope. That is exactly the kind of value-add the dimension rewards.

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-loaded with purpose, then chained use-case and duplicate-check guidance in two dense sentences. Every clause earns its place, though the duplicate-check rule packs three conditions into one long sentence that could be split for readability.

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 values need no explanation, and the description still covers the cap, the truncation flag, auth scope, and downstream tool usage. Nothing an agent needs to call this correctly 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 coverage is 0% and the single 'limit' parameter has no description, so the description compensates by stating the default (50) and the maximum (200). It does not explain whether 'truncated' responds to limit specifically, but the essential meaning is conveyed.

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 ('List the targets registered in your workspace') with clarifying scope: agents and MCP servers, including what each row carries (latest run status, endpoint_host). It is immediately distinguishable from create_target, list_runs, and the profile tools in the sibling list.

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 to alternatives: use the returned model_id with trigger_assessment or list_runs, and use this as the duplicate check before create_target. It even specifies the matching rule (same name + endpoint_host in same environment = same target; partial match = ask the user), leaving nothing to inference.

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