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 genuine behavioral context beyond them: pagination is fixed at 100 per page and the next_cursor must be fed back as cursor. It also notes that each returned item describes itself in an `effect` field, which is useful pre-call information.

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 compact sentences with the kind distinction and pagination rule front-loaded; nothing is padding. The phrase 'the ones Resolve offers' is slightly vague but adds product context rather than noise.

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 four-parameter, non-required, read-only list tool with no output schema, the description covers what is listed, the kind switch, and pagination mechanics. The only real gap is that the item shape is only hinted at via the `effect` field, which is acceptable given the tool's simplicity.

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 100%, so every parameter is already documented in the schema, including the kind default and the next_cursor-to-cursor mapping. The description largely restates those facts rather than adding new semantics such as valid kind values beyond the two listed or what happens with an expired cursor. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource: lists the workspace's call outcomes (kind=call, default) or ticket outcomes (kind=ticket). The two variants are distinguished inline. It stops short of naming a sibling tool it is not, so it does not reach the top band.

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?

There is no explicit when-to-use or when-not-to-use statement, and no alternative is named. The agent must infer that this is a discovery/lookup tool, presumably to obtain valid outcome values before setting one via desk_set_activity_outcome, but that inference is never stated.

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