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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description's main job is to add context beyond that. It does add one useful constraint - the payload must be bounded structured data and binary bytes are rejected - but says nothing about conflict handling, payload size limits, what happens to an existing asset with the same key, or the reliance on idempotencyKey for retries (that detail lives only in the schema).

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?

A single sentence, with the action and the primary restriction front-loaded and no redundant restatement of the name or schema. Nothing in it is filler.

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 seven-parameter mutating tool with a nested object, two required fields, and no output schema, the description omits what an agent would want: the relationship to create_presentation_request/start_presentation_build, what the call returns or when it fails, and what 'bounded' means operationally. The annotations and rich schema cover a lot, but the one-sentence description leaves real gaps for a mutation of this complexity.

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 100%, so the structured field already documents all seven parameters, including the retry semantics of idempotencyKey and the 'owned project ID' constraint. The description adds no parameter-level meaning of its own beyond the general statement about bounded structured content, so baseline 3 applies.

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 pairs a specific verb ('Store') with a specific resource ('presentation specification') and constrains the payload ('bounded structured', 'without accepting binary asset bytes'), which is more precise than a generic write tool. It does not, however, differentiate itself from close siblings such as presentation_write, create_presentation_request, start_presentation_build, or presentation_read, so an agent cannot tell from the text alone why this store exists alongside them.

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 statement, no prerequisite (e.g., that a presentation request must be created first), and no named alternative for the binary-asset case the description excludes. The exclusion of binary bytes implicitly points elsewhere but never says where, leaving the agent to guess between the several other presentation tools.

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