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

The description goes well beyond the annotations: it discloses the tool only proposes, never creates, requires human approval, provides an approvalUrl, and forbids using the contactId before approval. This is exactly the kind of behavioral context annotations cannot convey. No contradiction with readOnlyHint=false since it still creates a pending change.

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 a bit long but front-loads the critical caveat and each sentence adds workflow or usage information. The phrase 'and never will on its own' is slightly redundant with 'does NOT create anything in Xero itself,' but overall it is structured and readable.

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 tool with no output schema, it usefully names the approvalUrl field and the required approval step, and explains downstream use of contactId. It does not describe the full response shape or mention list_pending_changes/approve_xero_pending_change as related workflow steps, but an agent has enough to invoke it correctly.

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?

Only 'organisation' has a schema description (25% coverage), and the description only restates that 'name' is required, which is already in the schema. It adds no meaning for phone or emailAddress beyond their self-explanatory names, so it does not compensate for the low schema coverage.

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 uses a specific verb ('Proposes adding') and resource ('new contact (customer or supplier)') and immediately clarifies it does not create anything in Xero itself, distinguishing it from a plain create tool and from siblings like create_xero_invoice. It also names downstream consumers of the resulting contactId, which further disambiguates its role.

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 clearly states this queues a pending change requiring human approval and that the contactId can only be used after approval, giving an agent the context to decide whether to call it. It does not explicitly contrast it with update_xero_contact or list_xero_contacts, so there are no formal exclusions.

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