document_intelligence_create_slide_deck

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

The description adds some context beyond the annotations by explaining that the action routes through the platform's domain-agent dispatcher and runs under JWT, tenant, and company scope. It also notes that `message` is a free-text objective, implying open-ended behavior. However, given `destructiveHint: true`, it does not disclose what side effects or changes the action may trigger.

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?

The description is compact and front-loaded with the action name, followed by concise argument definitions. There is no redundant filler, though the routing sentence occupies space that could have been used for more substantive behavioral or usage guidance.

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 tool that creates an artifact through an agent action, the description is incomplete: it does not explain what a call is expected to produce, what structured inputs are supported, when the action is appropriate, or what destructive or side effects may occur. The output schema exists, but selection and invocation still require inference from the tool name.

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 carries the burden of explaining parameters. It gives basic semantic roles for both params: `message` is the free-text objective and `inputs` is an optional JSON string of structured inputs. This is helpful, but the description does not provide examples, accepted keys for `inputs`, or guidance on how to write an effective `message`.

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 tool as running the `document_intelligence` domain agent action `create_slide_deck`, so the resource and action are named. However, it relies on the tool name for the actual meaning and does not state what creating a slide deck involves, nor does it distinguish this from the sibling `create_slide_deck` or other document-intelligence creation tools.

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 about when to use this tool versus the generic `create_slide_deck`, `document_intelligence_create_report`, or other document-creation siblings. The description only explains routing mechanics (JWT, tenant, company scope), not selection criteria or prerequisites.

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