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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and the description is consistent with and additive to that: it explicitly says nothing is opened or executed, that the return value is a step-by-step guide, and that follow-through requires the browser tools. The MYOB API explanation (access form, app registration, per-file OAuth consent) supplies genuine context for why this tool exists. It doesn't describe the shape or granularity of the returned steps (e.g. customer vs supplier payment flows), which caps it below 5.

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 critical points are front-loaded: what it returns and that it opens nothing appear in the first sentence. However, the closing paragraph about MYOB's REST API, support forms, app registration and OAuth consent is long, tangential to invoking this tool, and reads as background research rather than operational guidance. It could be compressed to one clause justifying the browser fallback.

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 agent still needs to know what the returned guide covers and which payment scenario it addresses, and that is unstated. The definition does cover the key operational facts (no side effects, next step is browser automation). The missing piece is scope: whether the steps apply to customer receipts, supplier payments, or both.

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?

With zero parameters and 100% schema coverage, the baseline is 4; the description adds no parameter meaning because there is none to add. It does not explain that the guidance returned is therefore generic rather than scoped to a specific invoice or payment, which is a small missed opportunity, but nothing is misleading.

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 does the essential work of correcting the name: it states the tool 'Returns how to do it in MYOB step by step (screens, buttons, fields) and opens nothing by itself,' so an agent learns this is an instruction-generating tool rather than a mutating one. The verb+resource ('record payment in MYOB') is specific, and the handoff to cotlet_browser_* tools makes the role distinct. It stops short of differentiating from the myob_create_invoice / myob_create_bill siblings, so not a 5.

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?

Usage is implied rather than stated: call this first, then execute the returned steps with cotlet_browser_*. There is no explicit when-not guidance and no mention of the other myob_* tools an agent might confuse this with. The API paragraph indirectly argues for the browser path, but the agent must infer that this is the fallback when API access is unavailable.

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