SPACE-CORE

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

The annotations already declare destructiveHint=true and idempotentHint=false, and the description builds on that with concrete consequences: the mission is marked FAILED, no reward is paid, ship_status is reset to IDLE, a mission slot is freed, and all progress is lost irreversibly. This goes well beyond the generic hints.

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?

Three tightly packed sentences lead with the effect, then the state reset, the irreversibility warning, and finally a usage example. Nothing is redundant and the most decision-relevant facts (no reward, irreversible) come early.

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 destructive one-parameter mutation with no output schema, the description covers the outcome and the irreversibility. The remaining gap is failure behavior (unknown or already-terminal mission_id, wrong ownership), but otherwise an agent has everything it needs.

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 description coverage is 100% and covers both the bearer fallback and 'player_mission_id to abandon', so the schema explains most of the meaning. The description only adds the qualifier that the mission must be 'active', qualifying a parameter whose semantics are already documented, so the baseline of 3 applies. For example, it does not say what happens if the ID is already FAILED or COMPLETED.

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 names a specific verb and resource ('Abandon a ... active mission') and immediately states its effect: marks it FAILED, grants no reward, and resets ship_status to IDLE. This clearly distinguishes it from siblings like complete_mission, accept_mission, and cancel_order (which is for orders, not missions).

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 states when to use it ('stuck or unwanted active mission') and gives a concrete scenario: escaping a COMBAT mission accepted in a High-Sec sector where no pirates are reachable. There is no explicit 'when not to use' or named alternative, but the domain is clear enough that an agent can select it confidently.

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

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

Beyond annotations, the description discloses important behavior: mission slot limits by rank, the ability to hold several missions, the need to free slots when full, partial delivery behavior, and the mining-mission restriction that bought ore does not count. These details materially help an agent avoid failed calls.

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 front-loaded with the core action and parameter source, then proceeds to prerequisites and edge cases. Every sentence adds operational value, including the final mining-mission caveat.

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 mutation tool with no output schema, the description is rich about prerequisites, capacity, and alternatives. It could be slightly more complete by hinting at the response or error behavior after acceptance, but the operational guidance is otherwise strong.

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 description coverage is 100%, so both template_id and mission_id are already explained in the input schema. The description repeats that template_id comes from list_missions and that mission_id is an alias, but adds little parameter syntax or format detail beyond the 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 and resource: accept a mission using template_id from list_missions. It distinguishes this operation from sibling tools by naming list_missions as the source, abandon_mission for freeing slots, and complete_mission for partial delivery.

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 explicitly gives prerequisites (ship must be IDLE, DOCKED, or ON_MISSION) and alternatives for edge cases. When mission slots are full it directs the agent to abandon_mission, and when cargo exceeds hold capacity it directs partial completion via complete_mission.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered structurally; the description still adds value by stating the action is damaging and not reversible and that a combat result is returned. It does not cover failure modes (target absent from sector, cooldowns, death consequences), which keeps it below a 5.

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?

Three tight clauses with the highest-stakes disambiguation (PvP vs PvE) front-loaded, followed by the consequence and return signal. No filler sentences; every clause carries routing or behavioral information.

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?

No output schema, but the description notes a combat result is returned and states the key precondition (target in current sector). Missing detail on error cases and whether the attacker can be destroyed in return, which matters for a destructive PvP action.

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%, so both parameters are already documented, including the bearer fallback. The description only reinforces that targeting is by exact username and that the target must be in the current sector — useful but essentially duplicative of the schema. Baseline 3 is appropriate.

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?

States a specific verb (attack) and resource (another PLAYER pilot) plus the scoping mechanism (target_username, same sector). It explicitly excludes the pirate/PvE case, which is the closest sibling path (execute_action action=FIGHT), so the agent can separate the two without opening schemas.

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?

Gives explicit when-to-use (PvP against a player pilot in your sector) and when-not-to-use (pirates are attacked via execute_action action=FIGHT, optionally with pirate_id), naming the alternative tool and the condition that selects it.

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

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

Annotations already declare destructiveHint=true and non-idempotent, so the description is not carrying the safety burden alone — but it still adds real value: it spends CWM, consumes cargo space, returns amount bought and total cost, and cannot be undone, with selling back only at sell price minus taxes and fees. It stops short of saying what happens if stock or cargo space is insufficient for the full quantity (partial fill vs. rejection), which is the main remaining ambiguity for a destructive trade.

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?

Six short sentences, front-loaded with the action and the docked precondition, then alternatives, then effects. Dense but every sentence carries either routing or consequence information; the closing taxes-and-fees remark is the only slightly peripheral detail.

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?

No output schema exists, and the description compensates by stating the return payload (amount bought and total cost). Combined with stated costs, cargo consumption and irreversibility, an agent has nearly everything needed; the unstated partial-fill/insufficient-funds behavior is the only notable 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 description coverage is 100%, so item_code, quantity and bearer are already fully documented including the CWM/cargo/stock limits. The description adds only ambient context ('at the current price') and no additional parameter-level syntax or format guidance, so baseline 3 applies.

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?

States a specific verb and resource ('Buy goods instantly from the station market at the current price') and immediately differentiates itself from two siblings by naming a market-order execution semantic. An agent can distinguish buy from estimate_purchase and place_orders without opening any schema.

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?

Explicitly routes the agent: use estimate_purchase to check price first, use place_orders (type BUY) for a limit order, use this tool for an immediate market fill. It also states the precondition 'Ship must be docked', so both the when and the prerequisite are covered.

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

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

Goes well beyond the annotations: it discloses the refund of reserved CWM/goods, per-order partial-failure semantics ('one result per order, success or error each'), the behavior for already filled/cancelled orders, and the docking-free requirement. These are exactly the mutation-side facts annotations do not carry, and nothing contradicts destructiveHint=false/idempotentHint=false.

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?

Four tight sentences that front-load the action and its side effect before the parameter mechanics. Slightly dense with domain jargon (CWM, docking), but no sentence is filler.

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?

No output schema exists, and the description compensates by explaining the per-order result shape and error behavior. Minor gaps remain: what happens if both order_id and order_ids are supplied, and the bearer fallback is left entirely to the schema.

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%, so the 50-item cap, comma-separated form and id source are already documented in the schema. The description restates those and adds only the single-vs-multiple selection intent, which is the baseline-3 level of added meaning.

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?

Specific verb plus resource: 'Withdraw one or several of your own open order-book orders', with the id source (my_orders) named so it is distinguishable from order-listing siblings. It also states the side effect (reserved CWM for BUY, goods for SELL are returned), which makes the operation unambiguous.

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?

Says explicitly to use order_id for a single order and order_ids for several, and points at my_orders as the source of ids. No explicit when-not-to-use case (e.g. what to do instead of cancelling a filled order), so it falls short of a 5.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, which alone would suggest a harmless write; the description adds the crucial behavioral fact that messages are public to every player and cannot be edited or deleted afterwards, so the agent understands the action is irreversible in practice. It does not cover rate limits or what a successful call returns, which keeps it short of a 5.

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?

Three short sentences, front-loaded with the action and audience, then the exclusion, then the irreversibility caveat. No filler and every clause carries information the agent needs before sending.

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 two-parameter no-output-schema tool, the description covers audience, size limit, irreversibility, and the private-message alternative. The only gap is that with no output schema present, it never indicates what a successful post returns (e.g., a message id or the echoed text).

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 description coverage is 100%, so both the bearer token and message parameters are already documented, including the 500-char limit that the description merely repeats. The description adds no syntax, formatting, or audience-targeting semantics beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Post a message to the global public chat'), plus the audience and size limit. It also explicitly distinguishes itself from the private-message path via execute_action DM_SEND, so an agent can tell the two apart without opening either schema.

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?

Explicit when-to-use ('global public chat that all players read') and when-not-to-use ('Not for private messages -- use execute_action DM_SEND for those'). The alternative is named along with the condition that selects it.

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

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

Annotations already declare destructive=true, idempotent=false, readOnly=false, and the description goes well beyond them: it discloses payout of CWM, mission closure, the NO_READY_MISSION error response contents (progress and remaining ticks), and a subtle non-idempotent behavior where a delivery mission may accept a partial delivery and request the remainder on a later call.

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?

Front-loaded with the core action and reward, then usage and edge cases. Dense but nearly every clause carries information; the third sentence is somewhat run-on with multiple failure behaviors packed together.

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?

With no output schema, the description still covers return-relevant behavior (reward payout, error code and its contents), and two optional params are fully documented. An agent has everything needed to call this correctly, including the partial-delivery follow-up pattern.

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%, so the baseline is 3, but the description adds selection semantics for mission_id (optional, auto-selects the first READY mission) and clarifies the bearer parameter's role indirectly. The added meaning over the schema is real but limited to one parameter.

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?

States a specific verb and resource (complete a mission) plus the side effect (claim CWM reward, closes the mission), which distinguishes it cleanly from siblings like accept_mission, abandon_mission, and list_missions.

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?

Explicitly explains the zero-argument path (omit mission_id to auto-complete the first READY mission) and routes the agent to list_missions or get_status for progress checking. The when-it-fails condition (NO_READY_MISSION) is also stated, leaving little to inference.

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

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

The description adds rich operational context beyond annotations: 10-minute validity, single use, no Authorization header required, token shown once and must be kept secret, and a play guide in the response. However, 'usable once' conflicts with the declared idempotentHint: true, since a retry with the same code will fail rather than reproduce the effect, so the retry-safety signal is misleading.

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?

Two tightly packed sentences with the trigger question front-loaded and parenthetical details (format, validity, secrecy) each earning their place. No filler.

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?

Covers prerequisites, response contents (token plus play guide), token handling requirements, and the follow-up call to get_status. Even without an output schema, an agent has everything needed to invoke and use the result 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?

Schema coverage is 100% and already documents both parameters, including the code format example. The description reinforces the code format and validity window, but adds no information about the optional model parameter beyond what the schema provides, so baseline 3 applies.

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?

States a specific verb and resource ('Exchange the one-time code ... for your own Bearer token') and identifies itself as the pre-auth bootstrap, clearly distinct from token-requiring siblings like get_status. An agent immediately knows this is the credential-acquisition step.

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 trigger condition is explicit ('No token yet?') and the description routes the agent onward to get_status after success. It does not spell out a when-not-to-use case, but the bootstrap context is unambiguous.

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

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

Beyond the annotations, the description discloses that docking changes ship status to DOCKED, may charge a station fee in CWM that scales with ship tier and foreign-corp tolls, and fails when no station exists. These are meaningful side effects and cost conditions for a non-readOnly, non-destructive, idempotent action.

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 front-loaded with the action and required prerequisites, then compactly covers auto-selection, failure, status change, fees, and undocking. Every sentence contributes operational information without wasted preamble.

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 mutation tool with no output schema, the description covers the critical behavioral details: prerequisites, optional parameter behavior, failure mode, status change, fees, and related undock behavior. There is no obvious missing information needed 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?

Schema coverage is 100%, so the schema already documents both parameters. The description still adds useful semantics for station_id by explaining auto-selection when omitted and that IDs come from get_sector; bearer behavior is left to the 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 gives a specific verb and resource: 'Dock at a station in your sector.' It also distinguishes this tool from siblings by naming the actions that require docking first and by pointing to get_sector for station IDs.

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 explicitly states when docking is needed, how to omit station_id for auto-selection, what failure condition to expect, and how to leave the docked state with undock or implicitly via mine and warp. This is unusually complete routing and prerequisite guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Changes nothing' while adding value the annotations cannot: the docking prerequisite and the fact that the quote is time-sensitive ('RIGHT NOW') and includes the caller's own price impact. It could go further on rate limits or quote staleness, but the added context is substantive.

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?

One front-loaded sentence establishing the dry-run framing, followed by two clipped fragments for the no-side-effects guarantee and the docking prerequisite. Dense but every clause adds information an agent needs.

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?

There is no output schema, and the description compensates by enumerating precisely what the estimate returns (unit price with price impact, tax, total, affordability, cargo fit, stock level). Combined with the stated prerequisite, an agent has everything needed to call this 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?

Schema coverage is 100%, so the schema already documents item_code, quantity, and bearer. The description restates 'item_code x quantity' and frames quantity as intended purchase size, but adds no format or constraint detail beyond the schema. Baseline 3 applies when the schema carries the load.

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?

States a specific verb and resource ('Dry-run for buy: shows what buying item_code x quantity would cost') and enumerates exactly what is computed: unit price including own price impact, buy tax, total, affordability, cargo fit, and station stock. This clearly separates it from the sibling 'buy' tool, which would perform the transaction rather than simulate it.

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?

'Dry-run for buy' plus 'Changes nothing' makes the use case obvious: call this before committing to a purchase. The prerequisite 'Ship must be docked' is stated. It stops short of explicitly naming 'buy' as the alternative or stating when not to use it, but the routing signal is strong.

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

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

Beyond the destructive/non-idempotent/non-readonly annotations, it discloses that read actions cost no 10-second action tick while state-changing actions do and can be irreversible, and that LIST_ACTIONS is read-only and costs no tick with 25-per-page paging. It also implies a confirmation-based path via params for destructive actions. This adds substantial value the annotations don't carry.

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 routing rules and behavioral guidance are front-loaded and earn their place, but the inline enumeration of all 239 action names is a large, hard-to-parse block that is largely redundant with the LIST_ACTIONS discovery mechanism the description itself recommends. Useful content, but bloated and not front-loaded in the enumeration portion.

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 an extremely complex 128-parameter catch-all with no output schema, the description is impressively complete: it explains the fallback model, discovery via LIST_ACTIONS, tick/irreversibility behavior, and param passing conventions. Minor gap is that it doesn't describe the response shape or error handling, but with no output schema that burden is lighter.

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% so per-parameter meaning is already documented. The description adds real cross-cutting semantics: action name in UPPER_CASE, parameters passable flat or bundled in params with flat winning on conflict, and LIST_ACTIONS accepting params {group, offset} with next_offset paging. That exceeds the 3 baseline for a fully documented 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?

States a clear verb+resource with precise scope: a fallback executor for game actions lacking a dedicated tool, broken out by domain (corporations, crafting, drones, planets, contracts, ships, skills, DMs, pirate fights, anomalies). It explicitly names the siblings it must NOT replace (buy, sell, warp, dock, mine, missions, fleet, PvP attack), so an agent can distinguish it from those without opening schemas.

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?

Explicit when-to-use (only actions with no dedicated tool), when-not (the long list of dedicated tool equivalents), and a discovery path (action=LIST_ACTIONS, group=... with paging). It also tells the agent to call the matching list/info action first before state-changing actions. Alternatives and exclusions are both spelled out.

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

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

Annotations already declare destructive/non-idempotent/non-readOnly, and the description adds real side-effect detail beyond that: warp moves ALL members at once, fight requires every member on the same pirate_id in the SAME sector, target_id=0 clears the lock. It does not say whether disband or leave is reversible or what the fleet state becomes after a leader leaves, which for a destructiveHint=true tool is a remaining gap.

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?

Front-loaded with scope and the exclusion first, then a dense but information-bearing action list where every clause carries a permission or effect. The parenthetical chains are hard to scan for 12 actions, but no sentence is padding.

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 12-action, 9-parameter destructive dispatcher, the description covers permissions, cross-member side effects and per-action preconditions well. It stops short on failure behavior (what happens when a non-member is invited, what a fleet looks like after disband) and there is no output schema to carry return-value context.

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 description coverage is 100% and each parameter already carries its own 'For <action>' note including the mode enum and the target_id=0 convention, so the description mostly restates it. The only value added beyond the schema is the get_sector cross-reference for finding pirate_id and the fact that action accepts exactly those 12 values.

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?

Names the resource (corp fleet of several pilots), states that dispatch is via the action parameter, and enumerates all 12 actions with their effects. It also explicitly carves out the nearest confusion point ('Not for your own ships -- that is execute_action SWITCH_SHIP'), so an agent can separate it from execute_action without opening a schema.

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?

Gives explicit gating conditions per action (leader only, CEO/DIRECTOR to create, Admiral T3 for create/warp), plus a sequencing hint ('invites -- read before accept/decline'). It never routes to the sibling `warp` or `attack` tools, even though the fleet warp/fight actions sit adjacent to them in name and function, so one ambiguity remains.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds genuinely new context: the hangar is corporation-shared, so results are common across members rather than scoped to the caller, and mutations must go through execute_action. It stops short of describing pagination, empty-hangar behavior, or diff timing between calls.

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?

Two sentences with zero filler; the identification of the resource and its returned fields is front-loaded, with the sibling/mutation routing following. Every clause carries distinct information.

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?

No output schema exists, yet the description discloses the returned fields, the sharing scope, and the correct path for state changes — enough for an agent to call it correctly and interpret results. Not needed: safety profile, which annotations already carry.

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 is a single optional parameter (bearer) with 100% schema description coverage, and the schema already explains that it is only needed when the Authorization header cannot be sent. The description adds nothing about parameters, which is acceptable at full coverage but earns only the baseline.

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?

States a specific verb+resource ("List items stored in your corporation hangar") and names the returned fields (item code, name, quantity). It explicitly distinguishes the resource from get_inventory and station storage, so an agent can tell the three apart without opening any schema.

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?

Names the alternatives (get_inventory for personal cargo, station storage) and the exact mutation path for related operations: execute_action with CORP_HANGAR_DEPOSIT / CORP_HANGAR_WITHDRAW. That is an explicit use-here / use-elsewhere routing rule rather than implied usage.

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

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

The 'Read-only' claim merely repeats readOnlyHint=true rather than contradicting it, so no annotation conflict. The description does add real context beyond the annotations: results are implicitly scoped to the agent's current sector (no sector argument), the shape of each returned record is named, and the hand-off to jump_hyperlane is described. It stops short of noting whether the list is exhaustive or paginated.

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?

Three tight sentences with zero filler: what it lists and returns first, safety note second, alternatives third. Front-loaded and scannable.

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-required-param, read-only listing tool with no output schema, the description covers purpose, scope, returned fields and alternatives. Only minor gaps remain, such as whether the result set can be empty or large.

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 description coverage is 100% and the sole parameter (bearer) is documented in the schema, so the baseline is 3. The description's silence on bearer is acceptable, and the implicit statement that the sector comes from the session rather than a parameter is a small extra clarification rather than parameter documentation.

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?

States a specific verb and resource (list hyperlane links) plus the explicit scope 'that start in your current sector', and previews the returned fields (lane_id, destination sector, fuel cost). An agent can distinguish this from warp and get_route without opening any schema.

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?

Gives explicit routing: pass a lane_id to jump_hyperlane to actually travel, use warp for ordinary neighbours, and get_route for a distant path. When-to-use and which alternative applies in which case are both stated.

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

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

Annotations already declare readOnlyHint/destructiveHint, but the description adds genuinely non-obvious context: no docking is required, and the value shown is gross before taxes and fees rather than the actual sale payout. It stops short of describing pagination or ordering, but the safety and side-effect profile is clear.

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?

Front-loads what is returned, then the scope exclusions, then the usage pointer. Three short sentences with no filler; every clause carries information.

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?

With no output schema, the description still enumerates the returned fields and clarifies the valuation semantics, and it tells the agent the call is safe and dock-free. Nothing needed to invoke it correctly is missing.

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% and the single optional bearer parameter is fully documented there, so the description need not repeat it. No additional parameter meaning is offered, which is acceptable at this schema richness.

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?

States a specific resource (items in ship cargo hold) with the attributes returned (quantity, estimated gross value) and explicitly carves out what it is not: station storage and corp hangar. An agent can distinguish it from get_corp_hangar without opening either schema.

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?

Gives an explicit trigger ('Use before sell or sell_all to see what you carry') and negative guidance ('not station storage, not the corp hangar'), naming the sibling tools it should precede.

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

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

Beyond the read-only annotations, the description discloses that prices are current-station-only, that amounts are NET after sales tax, and that results are capped at 200 rows. These details materially affect how an agent interprets and relies on the returned data.

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 front-loaded and efficient, with the core purpose, filters, scope limit, and sibling alternatives all stated clearly. It repeats the category list already present in the schema, which is mildly redundant but still usable for quick routing.

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?

With no output schema, the description must carry return-value context, and it does so by stating that results include prices, item names, and net after-tax amounts. It also gives a row cap, though it does not describe the exact response shape or pagination behavior.

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 description coverage is 100%, so q, tier, category, and bearer are already documented in the schema. The description reinforces the category values and search semantics but does not add parameter syntax or constraints beyond what the schema already provides.

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-resource pair: it returns station market prices for the current sector, including item names and net proceeds after sales tax. It also explicitly distinguishes itself from get_price_history, get_module_listings, and trading tools like buy/sell, so an agent can identify its scope without opening the schema.

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 explicit routing: use get_price_history for prices over time, get_module_listings for player-offered used modules, and buy/sell/sell_all/place_orders to trade. The filter parameters and 200-row cap further clarify when and how to use this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description's 'Read-only' largely restates it. It does add value by disclosing the exact fields returned and the downstream purchase path, though it says nothing about result size, pagination, or whether listings are sector-scoped.

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?

Three short sentences, front-loaded with the resource and its returned fields, then the buy path, then the contrasting alternative. No filler; the 'Read-only' clause is the only near-redundancy.

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?

There is no output schema, and the description compensates by listing the returned fields plus the action needed to act on a listing. Minor gaps remain around whether results are global or sector-limited and whether the list is bounded.

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 one optional parameter (bearer) with 100% schema description coverage, so the schema fully documents it. The description adds no information about the token, which is acceptable given the baseline, but it doesn't compensate with anything extra.

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?

States a specific verb and resource (list used module offers on the module market) and enumerates the returned fields (listing ID, module name, quality, price, seller sector). It explicitly distinguishes itself from execute_action SHIPYARD_MODULES, so an agent can tell what data it gets without opening a schema.

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?

Names the follow-up action for buying (execute_action MODULE_LISTING_BUY with listing_id) and names the alternative source for new modules (SHIPYARD_MODULES). Both when-to-use-this and when-to-use-something-else are explicit.

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

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

Goes well beyond the annotations by disclosing the ordering (newest first), the mutation trigger (mark_read=true marks returned items as read, consistent with readOnlyHint=false), the cross-tool side effect where get_status marks shown notifications as read, and the shape of the return value (type, text, timestamp).

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?

Three dense sentences, front-loaded with what it does and the default behavior, then the mutation caveat, then the return format and a usage cue. The parenthetical about get_status earns its space because it prevents double-reading.

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?

With no output schema, the description compensates by naming the return fields (type, text, timestamp). Together with the mutation and default-behavior notes, an agent has everything needed to call it correctly and interpret the result.

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%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the default unread behavior and the non-obvious get_status interplay that affects how unread_only should be set. The bearer fallback and limit range are left to the schema, which is appropriate.

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?

States a specific verb (read), resource (notifications), scope (newest first), and enumerates the content types covered. It also distinguishes itself from get_status by explaining the interaction between the two, so an agent can tell them apart without opening either schema.

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?

Explicitly tells the agent when to call it ('check it after place_orders or mission work'), explains the default unread behavior, and names the alternative path (pass unread_only=false) for re-reading notifications already consumed by get_status.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful operational context that the tool needs no docking and returns timestamps plus a trend percentage, though it repeats that it is read-only.

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 front-loaded with the core purpose and scope, then usage context, then operational caveat. Every sentence contributes useful selection or invocation information without unnecessary repetition.

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 read-only annotations, full schema coverage, and no output schema, the description is complete enough to call correctly. It also summarizes the returned data as historical snapshots with timestamps and a trend percentage, which compensates for the missing output schema.

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%, so the schema already documents limit, bearer, and item_code. The description still adds value by specifying that item_code comes from get_market and that the history is for exactly one item, while reinforcing the limit range and default.

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 and resource: historical price snapshots for ONE item. It distinguishes itself from get_market by emphasizing history, timestamps, and trend percentage, so an agent can tell what it does without opening the schema.

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: judge whether the current station price from get_market is high or low before buy/sell or place_orders. It also says the tool needs no docking. It stops short of explicit when-not guidance, but the intended use is easy to infer.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description nevertheless adds real value beyond them: no fuel cost, ship does not move, and the return is a sector list to warp along yourself. Solid but the remaining gaps (error cases, cost of planning) are minor against full annotation coverage.

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?

Four short, front-loaded sentences with zero filler; the negative framing ('not fly', 'NOT autopilot') appears immediately, then usage, then the read-only guarantee.

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?

No output schema exists, yet the description explains what comes back (a sector list, plus a faster hyperlane variant when available) and confirms the call is side-effect free. That is everything needed to invoke and interpret the result 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?

Schema description coverage is 100%, so both bearer and dest_sector_id are already documented in the schema. The description adds no syntax or format detail beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb and resource ('Plan ... the fastest route to a distant sector') and preemptively disambiguates from near-siblings: 'not fly', 'NOT autopilot', warp hop-by-hop. An agent can distinguish it from warp and jump_hyperlane without opening any schema.

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?

Gives an explicit trigger condition — 'Use this whenever your destination is not a direct neighbour (warp fails with NO_ROUTE)' — and names the alternative it relates to (warp). Both when-to-use and the failure mode that forces it are specified.

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

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

Annotations already declare readOnlyHint/destructiveHint, but the description adds meaningful context: no docking required to call it, and the returned ids/names are exactly the inputs needed for dock, attack, and execute_action FIGHT. That inter-tool dependency disclosure is real value beyond the annotations.

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?

Dense and front-loaded — contents first, then usage, then the alternative tool. The telegraphic phrasing ('execute_action FIGHT', 'Use before mine') is efficient but slightly clipped.

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?

With no output schema, the description does the work of enumerating what is returned (security level, ore types, stations, pilots/pirates), which is sufficient for correct invocation. It stops short of describing response shape or id formats, a minor 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?

Only one optional parameter (bearer), fully documented in the schema at 100% coverage, and the description correctly implies no required inputs by saying it needs no docking. Nothing further is necessary, though the description doesn't mention the auth fallback itself.

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?

Names the resource ('the sector you are in') and enumerates the exact payload: security level, ore types, docking stations, and other pilots/pirates with ids/names. It is clearly distinguishable from movement tools like get_route and from get_status.

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?

Explicitly states usage conditions ('Use before mine, dock or execute_action FIGHT') and names the alternative for a different need ('To reach another sector use get_route'). An agent can decide between this and its sibling without further inference.

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

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

Annotations already declare read-only, non-destructive, closed-world behavior. The description adds useful context beyond those annotations: the returned fields, the no-corporation notice behavior, and that sovereignty requires corporation membership.

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?

Two compact sentences with no waste. The primary purpose and returned fields come first, followed by safety and alternative-action guidance.

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 simple read-only list tool with no output schema, the description supplies the returned fields, the no-corp edge behavior, the membership prerequisite, and where to go for claiming or releasing. That is sufficient for correct invocation.

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 bearer parameter is fully documented in the schema at 100% coverage, so the schema carries the parameter explanation. The description does not add further parameter meaning, which is acceptable given the high schema coverage baseline.

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 and resource: it lists sectors over which the caller's corporation holds sovereignty. It also names the returned fields (sector ID, name, security level, claim date), making it easy to distinguish from get_sector and other sector tools.

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 indicates the read-only listing use case and redirects mutation to execute_action SOV_CLAIM / SOV_RELEASE. It also notes the corporation-membership prerequisite, though it does not explicitly state exclusions beyond that.

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

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

Annotations already establish that this is not read-only, is idempotent, and is non-destructive. The description usefully explains the non-read-only behavior by noting that it marks shown notifications as read, and it discloses the leaderboard effect of the optional model argument. Minor auth/rate-limit details are left to the schema, but the important behavioral side effect is clear.

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 front-loaded with purpose, then usage guidance, then alternatives. Every sentence carries useful information, and the long field list in the first sentence is justified by the lack of an output schema.

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?

With no output schema, the description compensates by listing the status fields an agent will receive. It also covers when to call the tool, its side effects, and which sibling tools to use for related needs, making it complete for this tool's complexity.

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 description coverage is 100%, so both parameters are already documented. The description mentions the optional model argument and its leaderboard consequence, but this largely repeats the schema rather than adding new semantic detail; the bearer parameter is not discussed in the description.

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/resource: retrieving the player's own pilot and ship status. It enumerates the exact fields returned and explicitly distinguishes the tool from siblings like get_sector and get_inventory.

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 explicit invocation guidance: 'Call this first in every session and after any error.' It also names alternatives for adjacent needs: get_sector for the surrounding sector and get_inventory for cargo details.

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

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

Beyond the annotations, the description discloses important consequences: hyperlane jumps cost fuel and leave warp fatigue, and a docked ship undocks automatically with auto_undocked: true in the reply. This is exactly the kind of behavioral context an agent needs for a non-read-only, non-idempotent action.

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 tightly front-loaded: it states the action first, then the lane_id source, then side effects, then the alternative. Every sentence carries useful selection or invocation information.

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 simple two-parameter schema and the absence of an output schema, the description is complete enough to call the tool correctly. It covers the required lane_id source, fuel and fatigue costs, auto-undocking, and the warp alternative.

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 description coverage is 100%, so the schema already documents lane_id and bearer. The description only repeats that lane_id comes from get_hyperlanes and does not add format or edge-case semantics beyond the 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 and resource: 'Jump along a hyperlane'. It distinguishes this from sibling tools by naming get_hyperlanes as the source of lane_id and by explicitly contrasting it with warp for ordinary neighbour sectors.

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 explicit when-to-use guidance: hyperlanes are for named long-distance links, while 'For ordinary neighbour sectors use warp.' It also tells the agent where lane_id comes from via get_hyperlanes.

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

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

Annotations already declare readOnlyHint/openWorld/destructive, so the 'Read-only' opener is largely redundant, but the description adds real behavioral detail beyond them: the default top-15-by-profit ordering, the 'N more' paging line, the HOLD TOO SMALL marking, and the much-longer reply under detail=1. It does not discuss auth failure modes beyond the bearer param, keeping it from a 5.

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?

Front-loaded with the action and default output, then one clause per capability. It is dense and somewhat run-on, and 'Read-only' duplicates the annotation, but nearly every clause carries actionable information.

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?

With no output schema, the description carries the return-shape burden and does so: active vs available sections, profit fields listed, paging line, special markers, and detail mode. An agent has everything needed to call and interpret the result.

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%, so 3 is the baseline, and the description earns an extra point by tying offset to the 'N more' line, restating the limit cap (max 50) and sort semantics in narrative form. It adds modest but genuine connective meaning over the per-parameter schema text.

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?

Opens with a specific verb+resource ('Lists your active missions') and immediately specifies the default result shape (one line each, best 15 by profit). It also distinguishes itself from the mutation sibling by ending with 'Pass a template_id from the result to accept_mission.'

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?

Explicitly routes the agent: filtering via type/only_acceptable/no_goods, sorting via sort=profit|reward|duration, paging via limit/offset, and history/detail via the flags. It names the downstream alternative (accept_mission) and the handoff value (template_id).

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

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

Goes well beyond the annotations by disclosing side effects (auto-started mission, automatic undock with auto_undocked flag in the reply), the cargo gain being returned in the response, and the 10-second action tick that yields RATE_LIMITED. For a non-idempotent mutation this is exactly the context an agent needs.

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?

Front-loaded with the core action and secondary effects first, then preconditions, then the tick constraint. Dense but every clause carries information; the heavy dash chaining costs a little readability.

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?

No output schema exists, yet the description explains what comes back (cargo gain, auto_undocked) and what errors to expect (RATE_LIMITED), which is sufficient for an agent to call and interpret the result.

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 one optional auth parameter, fully documented at 100% schema coverage, and the description usefully clarifies that the tool is parameterless in substance and that the ore is determined by the sector. Little else could be added.

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?

States a specific verb and resource with scope ('Mine ore in the current sector right now') and adds a secondary effect ('auto-starts a MINING mission if none is active'). No sibling tool overlaps with mining, so an agent can select it unambiguously.

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?

Preconditions are spelled out precisely: ship must be IDLE or DOCKED with a mining module fitted, and a docked ship undocks automatically requiring a re-dock before sell/refuel/repair. It does not name alternatives, but none exist among the siblings, so the practical guidance is complete.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, while the description adds useful behavioral detail: default filtering/sorting, source restriction to place_orders, return contents, and cancellation path. It does not discuss pagination or auth behavior beyond the schema, so a 4 is appropriate.

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?

Front-loads the key scope and default behavior, with no filler sentences. The minor redundancy of 'Read-only' against annotations does not undermine its efficiency.

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?

There is no output schema, but the description names the returned list and its fields, while all four parameters are fully documented in the schema and annotations cover the safety profile. An agent has enough information to call 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?

Schema description coverage is 100%, and the schema already documents limit, bearer, open_only, and newest_first including defaults. The description echoes the default open/oldest-first behavior but adds no syntax or constraints beyond the schema, so the baseline 3 is correct.

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?

States a specific verb and resource: 'List your own order-book orders (BUY/SELL)' with returned fields. It explicitly distinguishes itself from place_orders and instant buy/sell trades, so an agent can select it confidently.

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?

Gives a clear default ('only OPEN orders, oldest first') and an explicit exclusion that instant buy/sell trades do not appear. It names cancel_order for withdrawal, but does not contrast with browsing tools like get_market, so it stops short of full alternative guidance.

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

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

Goes well beyond the annotations: it explains that orders rest in the book rather than executing immediately, that broker fee is charged at placement while buy tax hits on fill, that docking and funds are required, and that the reply is per-entry with partial failure tolerated. The destructiveHint/idempotentHint flags are consistent with this account of a non-idempotent, balance-affecting write.

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?

Four dense sentences with no filler: capability and scope first, sibling routing next, payload shape third, costs/preconditions/return semantics last. Front-loaded and every clause carries information.

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 batch mutation with no output schema, the description supplies what an agent actually needs: the entry shape, the fee/tax timing, the docking and funds preconditions, and the per-entry success/error return contract including partial-failure behavior.

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 already 100%, so the baseline is 3, but the description adds real meaning: 'at your own price' clarifies that price is the limit price you choose rather than the station price, and it restates the per-entry object shape and the 1-50 bound at the point of use. It stops short of adding any format or validation detail beyond the 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?

States a specific verb (put into the order book) plus resource (limit orders), the 1-50 batch scope, and the defining mechanic: orders fill later when matched. It distinguishes itself from the instant-trade siblings buy/sell by name, so an agent can route correctly without opening a schema.

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?

Explicitly names the alternative and the condition selecting it ('For an instant trade at the station price use buy/sell instead'), plus lifecycle routing to my_orders for viewing and cancel_order for withdrawal. Prerequisites (docking, funds) are stated too.

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

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

Annotations declare a non-readonly, non-idempotent, non-destructive local mutation, and the description adds real value beyond them: the dynamic price model tied to station reserves (2 to 20 CWM). It doesn't say what happens on insufficient credits or a full tank, but the cost behavior is disclosed.

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?

Three tight sentences: action and location first, then the cost model, then the parameter shortcut. No filler and nothing important buried.

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?

With no output schema, an agent might want to know what is returned (fuel added, credits spent) or the failure modes (insufficient credits, tank already full). Those are the only meaningful gaps; the pricing and unit semantics are fully covered.

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%, so baseline is 3; the description earns above that by explaining that the units parameter has a cost consequence driven by station reserve pricing, which the schema does not convey. The omission-equals-fill-tank rule is restated from the schema, adding little.

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?

A specific verb+resource ('Buy fuel') plus a stated precondition ('at your current docked station') that separates it from the generic buy/sell siblings. An agent can tell immediately this is the refuel-at-dock action rather than a market order.

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?

Usage context is clear — you must be docked, and omitting units fills the tank. There are no explicit exclusions or pointers to alternatives (e.g., that buy/place_orders handle other commodities or larger fuel purchases), so it stops short of full routing guidance.

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

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

Beyond the annotations, the description discloses the per-call healing cap, the armor healing rate, the exact cost formula with tier multipliers and reputation/skill discounts, and that it stops when funds run out. This is rich behavioral context for a non-read-only, non-idempotent mutation tool.

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 central purpose is front-loaded, but the description crams an intricate cost formula with nested parentheses into a single dense sentence. Every detail is relevant, yet the structure could be split for easier parsing.

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?

There is no output schema, and the description mentions that the reply shows calculation details in price_info. It covers prerequisites, caps, and stopping conditions well, though it could clarify behavior when not docked.

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 schema covers its single bearer parameter at 100% coverage, so it does the heavy lifting. The description adds no parameter-level meaning, but with one fully documented optional auth parameter, baseline 3 is appropriate.

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 gives a specific verb and resource ('Repair hull & armor') plus a clear location precondition ('at a docked station'). It also explicitly distinguishes itself from the sibling operation execute_action REPAIR by noting the shared per-call cap.

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 states the key precondition (must be docked), the repeat-until-full pattern, and the funds-exhaustion stop condition. It references execute_action REPAIR as an alternative with the same cap, but does not give explicit when-not-to-use guidance.

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

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

Beyond the annotations, the description discloses important behavior: reports go to game operators, duplicate reports are merged automatically, and repeated reports should not be filed. It also clarifies that ordinary game-rule failures are not actionable bugs, which is crucial for correct invocation.

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 long but front-loads the core purpose and then organizes exclusions and inclusion criteria clearly. The length is justified by the need to prevent false-positive bug reports, though it could be slightly tightened without losing meaning.

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 there is no output schema and the tool is a mutation/reporting action, the description covers the key decision criteria, exclusions, duplicate handling, and reporting expectations. An agent has enough information to decide whether and how to call 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?

Schema description coverage is 100%, so the schema already documents title, details, bearer, and category. The description does not add parameter-level format or syntax details beyond what the schema provides, so the baseline of 3 is appropriate.

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 and resource: report a genuine bug or broken behaviour to the game operators. It clearly distinguishes this from normal gameplay actions by listing what must never be reported and defining the exact conditions under which reporting is appropriate.

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 explicit when-to-use criteria in three named cases (contradicted rule, server error, implausible values) and explicit when-not-to-use cases such as cargo hold full, insufficient credits, cooldowns, and refused actions. It also tells the agent to err on the side of not reporting when in doubt.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the safety profile is covered. The description adds behavioral context annotations cannot express: the sale is immediate at station price and requires an explicit docking state. It does not mention the mission-reserve side effect or what the response contains, but the docking precondition and execution semantics make this above baseline.

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?

Three sentences, front-loaded with the core action, then the precondition, then the alternatives. No repetition of the title or filler.

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?

Covers action, scope, precondition, and sibling routing for a destructive trade tool with no output schema. The only gap is that it does not describe what a successful sale returns (units sold, credits received) or partial-failure behavior, which an agent may need to confirm results.

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%, so quantity, item_code, force, bearer and ignore_mission_reserve are all fully documented in the schema, including the mission-reserve warning and the force alias. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb ('Sell'), a precise scope ('ONE item type from your cargo'), and the execution model ('instantly at the station price'). The emphasis on ONE item type immediately separates it from sell_all and place_orders, so an agent can pick correctly without opening the schema.

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?

Names both alternatives with the condition selecting each: sell_all for everything, place_orders (type SELL) to wait for a better price. Also states the hard precondition 'Ship must be DOCKED (use dock first) -- being in a sector with a station is not enough,' pre-empting the most likely failure mode.

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

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

Annotations already flag destructiveHint=true, but the description adds the reservation semantics that determine whether anything sells at all, the prerequisite docking state, the pricing basis, and the explicit warning 'Irreversible.' It also compensates for the missing output schema by stating what comes back (items sold and CWM received).

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?

Four sentences, front-loaded with the action and the blocking prerequisite, then the reserve caveats, then the sibling pointer, then the return/irreversibility note. No filler and each sentence carries a distinct operational fact.

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-required-parameter mutation tool with no output schema, the description covers prerequisite state, collateral effects (reserved cargo), return content, and irreversibility. Nothing an agent needs in order to invoke it safely is missing.

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% and both optional flags are already fully documented in the schema, including the 'Nothing sold' consequence. The description's sentence about upgrade and mission reserves restates the same defaults rather than adding new semantics, so it does not exceed the baseline for fully covered parameters.

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?

States a specific verb and resource ('Sell every item in your cargo') plus the pricing model ('instantly at the station price') and explicitly separates itself from the single-item sibling 'sell'. An agent can distinguish it from 'sell' without opening either schema.

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?

Gives a hard prerequisite ('Ship must be DOCKED (use dock first)'), names the alternative for the narrow case ('For a single item use sell'), and explains the two opt-in flags that change what actually gets sold. When-to-use and when-not-to-use are both covered with named siblings.

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

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

Annotations already declare non-readonly, idempotent, and non-destructive behavior, and the description reinforces this with 'can be repeated safely.' It also discloses the ship status transition to IDLE. It does not mention failure modes or permission/authentication nuances, but covers the key behavioral traits beyond annotations.

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?

Four compact sentences, front-loaded with the action and result, then useful caveats and workflow constraints. Every sentence adds value and there is no wasted text.

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 parameterless state-transition tool with no output schema, the description covers purpose, side effect, idempotency, alternatives that make it redundant, and required follow-up actions. An agent has enough context 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?

Schema description coverage is 100%, so the schema already documents the optional bearer parameter fully. The description says 'takes no parameters,' which is slightly imprecise because an optional auth fallback exists, though this is minor and covered by the 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?

States a specific verb and resource ('Undock from your current station') plus the resulting state change ('set the ship status back to IDLE'). It is clearly distinguishable from sibling tools like dock, mine, and warp.

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?

Explicitly says the tool is usually not needed because mine and warp undock automatically, and it names when docking is required again (trade, refuel, repair). This gives clear when-to-use, when-not-to-use, and workflow context.

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

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

Adds behavior the annotations cannot express: a docked ship undocks automatically and the response carries auto_undocked: true, the action consumes fuel, and adjacency failure returns NO_ROUTE. These are exactly the side effects an agent needs before committing to a non-readOnly, non-idempotent mutation.

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?

Four short sentences, action and constraint front-loaded, then alternatives, then cost and failure mode. No filler and no repetition beyond the necessary adjacency restatement.

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?

No output schema exists, and the description compensates by naming the one response field that matters (auto_undocked: true) along with the error code. For a single-required-parameter mutation, nothing an agent needs to call it correctly is missing.

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% and the schema already describes sector_id as a 'directly connected neighbour sector (from get_sector)'. The description restates the adjacency constraint rather than adding syntax or sourcing details, so the schema is doing the heavy lifting.

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?

States a specific verb and resource: 'Fly to a directly connected neighbour sector (sector_id)'. It immediately distinguishes itself from the two obvious alternatives, get_route (planning) and jump_hyperlane (named long-distance lanes), so an agent can route correctly without opening any schema.

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?

Explicit routing guidance: use get_route to plan distant trips and warp hop by hop, and use jump_hyperlane for named long-distance lanes. It also states the failure precondition (non-adjacent sector yields NO_ROUTE), which tells the agent when not to call it.

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