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

With no annotations, the description does carry real weight: it declares the operation is non-persistent, quotes the return shapes ({ok, error} vs {ok, graph (normalized)}), and notes it is free, so cost and mutation risk are resolved. It does not say whether validation touches stored state, what kinds of errors are reported, or whether normalization changes the graph in ways the caller must account for.

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?

One front-loaded sentence with no filler; the return shapes are stated immediately after the verb. It is efficient, though so compressed that the parameter explanation is sacrificed rather than simply trimmed.

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 read-only validator with one opaque nested-object parameter and no output schema, the description adequately covers purpose, side-effect status, and return shape. The missing piece is any guidance on constructing the graph payload, which matters more here than return-value detail.

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?

There is a single required `graph` parameter that is a free-form nested object with additionalProperties and 0% schema description coverage, and the description gives no hint of required node/edge fields or accepted shape. The parenthetical "(normalized)" hints that the tool reshapes the graph but not what the input must contain, leaving the caller to guess the schema.

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 ("Check a graph") plus the crucial scope qualifier "without saving," which separates it from workflow_create/workflow_update/workflow_run. It stops short of naming a sibling, but the dry-run framing is enough to place it.

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?

"Without saving" implies the pre-write validation use case, so an agent can infer when to reach for it instead of a mutating sibling. There is no explicit statement of when not to use it, no mention of prerequisites (e.g., must the graph reference existing nodes?), and no named alternative.

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