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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the description only needs to add context — and it does: the body is returned as a JSON string exactly as authored, accompanied by content_sha256, and omitting version yields the latest. It leaves error cases (unknown slug/id, version not found) and slug-vs-id precedence unstated.

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 sentences, front-loaded with what is read and followed by what is returned and the default-version behavior. No filler, and the most decision-relevant facts come first.

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?

The tool is a simple three-parameter read with an output schema and full annotation coverage; the description covers retrieval scope, return shape, and the version default. Nothing needed to invoke it 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 100%, so all three parameters are already documented, including 'omit (0) for the latest version'. The description largely restates this ('omit version to get the latest version'; 'by slug or id') without adding precedence rules or clarifying whether both identifiers may be supplied. 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 ('Read back the full stored definition of a workflow version by slug or id'), which separates it from the version-less get_workflow and from schema-oriented siblings like get_workflow_definition_schema. It also names the return artifacts (definition body, content_sha256), so an agent knows exactly what it gets.

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 parenthetical about parsing the body 'to diff or patch and resubmit as a new version' gives a concrete usage context that implicitly chains to patch_workflow and create_workflow_version. It does not explicitly name alternatives or exclusions (e.g., when to use get_workflow instead), so it stops short of a 5.

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