sherweb_billing_charge_details

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

No annotations are available, so the description carries the transparency burden. It discloses what the tool returns (breakdown of line items, pricing, deductions, fees, tax), which is reasonable read-oriented context. It does not mention any side effects, permissions, or error conditions, but for a read/retrieval tool the absence of destructive hints and the clear return content is acceptable.

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?

A single, tightly written sentence that front-loads the core purpose ('Get detailed breakdown of a specific charge') followed by the payload contents. Zero wasted words, effective structure.

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 single-parameter lookup tool with no output schema and no annotations, the description adequately conveys the retrieval nature and what it returns. It could mention whether the call is read-only or include error handling guidance, but given low complexity (one param, no nested objects) and clear purpose, it is reasonably complete.

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 single parameter chargeId is described in the schema ('The unique charge ID to get details for') giving 100% coverage. The description adds context about the charge being specific and that it returns a breakdown, reinforcing the parameter's role. With only one parameter fully documented in the schema, baseline 3 is met, and the description's elaboration justifies 4.

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 ('Get detailed breakdown') with a clear resource ('specific charge') and enumerates the content returned (line items, pricing tiers, deductions, fees, tax information). It clearly distinguishes from siblings like sherweb_billing_payable_charges (which likely returns the list of payable charges) by focusing on the detail view of a single charge.

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?

No usage guidance is provided. The description does not state when to use this tool versus sherweb_billing_payable_charges or other billing-related siblings. No prerequisites, exclusions, or alternative tool references are mentioned.

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