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

Beyond the readOnly/idempotent/non-destructive annotations, the description states 'opens nothing by itself', defines the return content (screens, buttons, fields), and explains why no API path exists (no public API, webhooks, or Zapier; only built-in partners). That is genuine added context. It omits prerequisites such as whether the user must already be signed in to the Cloud Browser.

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?

Three sentences, each doing work: what it returns, how to act on it, and why browser automation is required. The partner list (Xero, QuickBooks, Stripe, Pic-Time) and the checked date are slightly tangential but substantiate the no-API claim. The lead sentence's imperative framing costs a little clarity.

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 zero-parameter guidance tool with no output schema, the description covers return content, execution path, and the absence of an API alternative. The main remaining gap is session/auth prerequisites for the Cloud Browser handoff, which an agent would need before acting.

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 is empty, so there is no parameter semantics to add; the baseline for a parameterless tool applies. Nothing in the description misleads about inputs.

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 resource and action (Studio Ninja invoice) and then clarifies that the tool actually returns step-by-step instructions rather than performing the send. This correction of the imperative-sounding name is valuable, though the opening sentence 'Send invoice in the user's own Studio Ninja account from ChatGPT' briefly suggests direct execution before the second sentence reverses it. It does not explicitly distinguish itself from siblings like studio_ninja_send_contract.

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 clear sequencing guidance: get the steps here, then execute with cotlet_browser_* tools in the Studio Ninja Cloud Browser. That is actionable workflow context an agent can follow. It stops short of saying when NOT to use it or how it differs from other studio_ninja_* action tools.

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