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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false; the description usefully reinforces this by stating the tool 'opens nothing by itself' and only returns procedural guidance, which prevents an agent from assuming the duplication has already happened. What it omits is any statement of prerequisites (e.g. an existing presentation, authentication context) or the format/length of the returned steps.

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 first two sentences are front-loaded and earn their place, but the trailing paragraph about Beautiful.ai's official API and MCP connector (including a dated 'checked 11 Oct 2026' aside) is tangential to invoking this tool and dilutes focus. A more disciplined version would fold the 'what it returns' point into the lead and cut the API digression.

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?

With no input parameters, no output schema and rich annotations, the definition is close to sufficient, and it does describe the return value at a high level. The significant unresolved gap is that a zero-parameter tool cannot specify which presentation to duplicate, and the description never explains how selection happens or what the agent should do to disambiguate.

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 tool takes zero parameters and the schema has additionalProperties=false, so there is no parameter semantics to explain; baseline for a parameterless tool applies. The description could still have explained how the target presentation is identified without arguments, but within this dimension it adds nothing that is needed.

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 opening sentence names a specific verb and resource (duplicate a presentation) scoped to the user's own Beautiful.ai account, which separates it from beautiful_ai_create_presentation. The second sentence clarifies the non-obvious nature of the output (step-by-step instructions rather than an executed action), though the phrasing 'Duplicate presentation ... Returns how to do it' initially reads as if the tool performs the duplication.

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?

It gives one concrete follow-on instruction: use the cotlet_browser_* tools to actually carry out the steps. However, it never states when to choose this over beautiful_ai_create_presentation (which presumably makes a new deck) or when duplication is unnecessary, and the closing paragraph about Beautiful.ai's official API/MCP connector muddies rather than sharpens the routing decision.

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