Record a product demo

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

Annotations only declare readOnly=false, openWorld=true, destructive=false; the description goes well beyond them by disclosing cost semantics (budgetUsd held while it runs and released), the required write scope, login-wall capture behavior, and the rendered output (MP4 with following cursor and camera). This is exactly the kind of behavioral detail annotations cannot convey.

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 front-loaded with the core mechanism before the caveats, and each clause carries distinct information (mechanism, output, login behavior, cost, auth). It is a bit dense and could break the budget/scope sentence out, but there is no 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?

With an output schema present the description needn't explain return values yet it still characterizes the MP4 output, and it covers auth scope, cost mechanics, and the login-wall edge case. The only gap is the missing differentiation from the record_page/screenshot_page siblings, which matters for correct selection.

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 every parameter is already documented, establishing a baseline of 3. The description echoes the budgetUsd default/max and the action vocabulary (type, click, hover, scroll, wait) but adds little syntax or format detail beyond what the schema already provides.

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 names a specific verb and resource ('A real browser opens a URL and performs the steps you name... returns an MP4 media key'), which clearly distinguishes it from a static screenshot tool. However, it never references its close siblings record_page or screenshot_page, so the agent must infer the boundary rather than being told.

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 a useful caveat ('A page behind a login demos as its login wall') and states the write-scope requirement, which implicitly signals when it is callable. But there is no explicit when-to-use-vs-alternatives guidance against the overlapping record_page/screenshot_page siblings, leaving the choice to inference.

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