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

Annotations already establish this as a read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuine behavioural detail beyond that: results are the 'real' history (actual executions, not simulation) and are paginated at 50 tasks per page. It does not say what happens with an invalid or unknown id, nor how far back the history reaches.

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, the content list front-loaded ahead of the pagination constraint, with no filler. It is efficient to the point of being slightly under-specified, but nothing is redundant.

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 two-parameter read tool with no output schema and pre-existing read-only annotations, the description covers the gist and the page limit. It nonetheless leaves the required 'id' undefined, which is the one thing an agent cannot safely guess before calling.

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 burden, and it only partially does — 'Pagination 50 tâches' clarifies the page size but not whether 'page' is 0- or 1-based, and it never says whether 'id' is a workflow id or a run id. The single required parameter, the most important one, is left ambiguous.

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 identifies the resource (a workflow's real execution history) and enumerates what it returns: contacts, steps, durations, errors and attempts. This clearly tells an agent it reads actual run history rather than configured definitions. It stops short of a verb phrase or of naming how it differs from neighbours like get_run, list_runs or describe_workflows.

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 guidance on when to pick this over get_run/list_runs/describe_workflows, nor any prerequisite such as needing a valid workflow or run identifier. The agent must infer context of use entirely from the tool name and sibling list.

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