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

Annotations only provide readOnlyHint=false, so the description carries the full behavioral burden. It does so thoroughly: all-or-nothing payment, reputation restoration up to the empire cap, effectiveness mid-jump and while docked, immediate release when detained, source routing details, listing-fee versus instant-fill behavior, and the interaction with gifts while detained.

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 information-dense and every clause adds value, but it is delivered as one sprawling parenthetical with semicolons and nested asides, making it hard to scan. It is long enough that an agent must parse carefully to extract the key edge cases. Structure could be improved with bullets or shorter sentences.

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?

Given the tool's complexity and the absence of an output schema, the description covers nearly everything needed to call it correctly: empire selection, funding source permissions, detention behavior, location independence, and fallback alternatives. It does not explicitly describe the success/error return shape, and it does not state what happens if neither self nor faction funds are available, leaving a small gap.

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?

Schema coverage is 100%, giving a baseline of 3. The description adds meaningful nuance beyond the schema: how to decide whether to omit or name empire, where to find the outstanding amount via get_status, and the fact that faction funds bypass the wallet entirely. This enrichment justifies a 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 identifies a specific action—paying missed taxes and outstanding bounties—and details the consequential effects: clearing every uncleared crime with one empire and restoring lost reputation. It clearly distinguishes this from related tools like prepay_tax by framing it as paying outstanding, already-incurred obligations.

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?

The description gives strong contextual guidance: when to pay, when it is critical to pay before docking, how detention interacts with payment, and when to omit or name the empire parameter. It also names practical alternatives such as sell and send_gift for raising bail. It does not explicitly contrast with prepay_tax or faction_prepay_tax, so it stops short of full when-not-to-use clarity.

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