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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description's "same every time / read-only / not metered" largely restates those. It does add genuinely useful behavioral context — transfer-session handles pass directly between tools with no re-upload, and workspace_tag makes steps callable rather than placeholder — but this describes the guide's contents more than the call's own behavior.

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?

For a zero-required-parameter, read-only guide fetch, roughly 170 words across three dense paragraphs is heavy, and much of it summarizes the guide's payload rather than helping select or invoke the tool. The lead sentence is well front-loaded, but the middle and closing material on statement types and file-format routing is only tangentially about this call.

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 schema is trivial, annotations cover the safety profile, and an output schema exists, so little is required; the description nonetheless conveys the workflow scope, the transfer-handle convention, and the optionality of charts. An agent can call this correctly and knows what class of content it receives.

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?

The single parameter is fully documented in the schema (100% coverage), so the baseline applies. The description does add one meaningful nuance the schema omits: an unauthorized or missing workspace_tag leaves host steps as host steps rather than producing placeholder calls, which tells the agent what happens on the failure path.

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 first sentence names a specific verb and resource — "Returns the FinStat workflow" — and the rest of the paragraph enumerates the workflow's subject matter, so an agent knows exactly what comes back. However, it makes no attempt to distinguish itself from the many sibling guide tools (guide_tasks, guide_glossary, examples, demo), which is the main thing an agent needs when several tools look like entry points.

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 guide is the same every time" and "Read-only and not metered" imply it can be fetched freely and repeatedly, but there is no explicit when-to-call framing or statement of how it relates to guide_tasks or examples. The routing advice present ("A QuickBooks Online export zip goes to create_standard_book", "a trial balance ... is not a statement") guides the agent on downstream steps rather than on selecting this tool.

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