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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, but the description earns credit by explaining why: the tool 'opens nothing by itself' and only returns instructions, so a zero-side-effect read is confirmed in prose rather than left to the hint. It also discloses the real-world blocker (MYOB API access requires a support request, app registration and per-company OAuth consent), which explains why browser automation is the path. It stops short of 5 because it does not say what the returned steps look like in structure or how they behave if the user's MYOB UI differs by region/plan.

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 operative content is front-loaded and correct, but the third sentence is a long, marketing-toned aside about MYOB's official API ('Yes, MYOB has a full REST API... checked 14 Oct 2026') with dates and registration minutiae that an agent does not need in order to call this tool. The core fact — return steps, then drive the browser — is compressed into one dense semicolon-joined sentence.

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 what it returns (step-by-step screens, buttons, fields), what it does not do (opens nothing), and the follow-up tool family. That is close to sufficient. It lacks only the preconditions for the handoff, such as whether a Cloud Browser session must already be open.

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 schema has zero parameters at 100% coverage, so the baseline is 4. The description is consistent with that: it is a generic how-to tool, not one that targets a specific invoice, so no parameter meaning is left unexplained. However, the total absence of any invoice identifier is worth flagging to callers, and the description never says so explicitly.

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 definition states the resource (MYOB sales invoice) and, crucially, corrects the misleading name by saying it 'Returns how to do it in MYOB step by step (screens, buttons, fields) and opens nothing by itself.' That distinguishes it from the cotlet_browser_* action tools it hands off to. It falls short of 5 because the opening sentence ('Send invoice in the user's own MYOB account from ChatGPT, Claude or any AI agent') still reads like an execution claim and no sibling such as myob_create_invoice is contrasted.

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 an implied workflow: get the steps here, then 'do it with the cotlet_browser_* tools in the user's MYOB Cloud Browser.' That is useful sequencing. But there is no explicit when-not-to-use, no statement of what the user must have in place (an open Cloud Browser session, an MYOB login), and no contrast with myob_create_invoice, which an agent could reasonably confuse with this.

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