xero_book_depreciation

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

With annotations already marking this as readOnly=false, destructive=true, and idempotent=true, the description adds useful behavioral context: it is gated through a governed connector authority, Spring verifies the claimed effect, and writes require an approval_ref when resuming. This goes beyond the annotations by disclosing an approval workflow and an effect-verification mechanism. It does not, however, describe what records or financial state the operation modifies.

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 concise and well-organized with a clean bulleted argument list. The opening sentence is somewhat redundant, restating the name and platform identifier, but the rest is compact and scannable. It earns a high score for structure, with minor redundancy keeping it from being perfect.

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?

Despite having an output schema, the description is incomplete for correct invocation: it never explains what 'book depreciation' actually does, what keys or values the `arguments` JSON string must contain, or how this operation fits with sibling Xero tools. An agent would need external domain knowledge to construct a valid call, so the description is adequate only as a generic connector envelope.

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 description provides one-line explanations for all seven wrapper parameters, which is valuable given 0% schema description coverage. However, the most important parameter, `arguments`, is described only as 'JSON string of arguments for the connector operation' — a circular explanation that gives no hint of the actual depreciation payload. The other parameter descriptions are meaningful but generic platform plumbing terms.

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 is essentially a tautology: it restates the tool name and platform identifier ('Xero connector operation `book_depreciation`') without explaining what booking depreciation does. The routing clause adds context but not purpose, and it does not distinguish this operation from siblings like xero_create_asset or xero_dispose_asset. A domain-naive agent cannot tell what business action this performs.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no examples. The only stated constraint, 'Routes only through the exact project/account governed connector authority,' is a routing restriction rather than a usage condition. The description does not say when booking depreciation is called for or when another Xero operation would be more appropriate.

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