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

The description says the tool 'opens nothing by itself' and returns step-by-step guidance, which contradicts the annotation readOnlyHint=true only in framing – though the annotation itself is suspect for a tool titled 'Create customer'. The bigger issue is the description never explains why readOnlyHint/destructiveHint/idempotentHint are set or what 'ERPNext's official API: Yes' means operationally. For a tool that is nominally a mutation but is annotated as read-only, the behavioral contract is not adequately explained.

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?

It is short and front-loaded with the core statement, but the second half crams multiple concerns (return format, non-action, browser follow-up, API status) into dense, slightly run-on clauses. 'ERPNext's official API: Yes' is cryptic filler that does not earn its place.

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 tool with an empty schema and no output schema, the description covers what happens (returns instructions) and what to do next (browser tools). But it leaves an important gap: it does not clarify how a tool named 'create customer' with readOnlyHint=true actually relates to creating a customer, nor does it describe the shape of the returned guidance.

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?

There are zero parameters, so by the scoring baseline a 4 is appropriate. The description adds meaning about what the tool returns (step-by-step ERPNext screens, buttons, fields) rather than parameter details, which is fitting given the empty schema.

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 states a specific verb (create) and resource (customer) and scopes it to the user's own ERPNext account, which distinguishes it from siblings like erpnext_create_sales_invoice. However, the purpose is muddied: the tool apparently does not create anything, it returns instructions. That ambiguity in what the tool actually is (guidance vs. action) blunts the clarity a sharp verb+resource statement would otherwise provide.

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 usage context: 'opens nothing by itself; then do it with the cotlet_browser_* tools in the user's ERPNext Cloud Browser.' That explicitly sequences this tool before the browser tools, which is genuinely useful routing. It lacks exclusions, though – it never says when NOT to use this (e.g., for creating payments or invoices, where siblings exist).

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