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

Annotations already establish that this is a read-only, open-world operation. The description adds useful behavioral detail by explaining that it returns per-item buy/sell unit prices, totals, volume, and unrecognized lines, which goes beyond the safety 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?

Two dense sentences with no wasted wording. The core action and default market are front-loaded, followed by accepted input formats and return contents.

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, read-only, no-output-schema tool, the description covers the input formats, default market, and return shape. With annotations covering safety and schema covering parameters, no critical agent-facing information appears 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%, so the schema already documents both parameters. The description still adds meaning by clarifying accepted free-form text formats and by naming the default location as Jita 4-4 beyond the schema's shorter 'jita' 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 uses a specific verb, "Values," and clearly identifies the resource as free-form item text, with concrete examples of accepted formats and a default market. An agent can distinguish this list-appraisal tool from general lookup or market-price 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?

The description implies when to use it by listing supported inputs such as EFT fits and inventory/cargo paste, but it does not explicitly state when to prefer it over siblings like market_prices or item_info, nor does it name exclusions.

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 a read-only, open-world operation. The description adds useful behavioral context beyond annotations: names and locations are resolved, values use CCP's universe average price, and ESI asset data may be cached for up to an hour.

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 compact and front-loaded: it identifies the resource, then mode behavior, then pricing and caching caveats. Every sentence contributes directly to correct invocation.

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 explains the return shape per mode: per-location counts and values for summary, location and container path plus totals for search, and named/located ships for ships. It also covers data freshness and valuation source, leaving no major gap for an agent 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 all parameters. The description still adds value by explaining what each mode returns and how search/summary/ships differ, exceeding the baseline for fully documented schemas.

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 resource (a character's assets) and concrete modes (summary, search, ships), making the tool's role clear. It does not explicitly distinguish itself from sibling tools such as search_items or appraise, so it falls short of the top score.

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 mode descriptions give clear context for selecting summary, search, or ships, and the schema adds the default-mode rule. It does not state when not to use this tool or name sibling alternatives, so it is clear but not exhaustive.

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 only declare openWorldHint, so the description carries most of the burden and does well: it discloses the side effect of opening a browser, that a URL is returned, and that the call blocks up to wait_seconds. It does not say what happens on timeout (error vs. pending), which is the one meaningful behavioral 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?

Four dense sentences, front-loaded with the action and mechanism before the repeat-use note and preset details. Every sentence carries information not present in the schema or annotations.

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 correctly notes that the URL is returned as part of the result, and covers blocking behavior and preset semantics. The only missing piece is failure/timeout outcomes for a call that can legitimately not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description genuinely adds meaning the schema lacks: it explains what each preset contains ('standard' = personal read plus fittings/mail/waypoint write, 'full' adds corporation scopes) and restates the wait_seconds 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?

States a specific verb and resource: 'Starts EVE SSO login', and immediately describes the mechanism (opens browser, returns URL, waits). It is unmistakably distinct from siblings like character_select, character_logout, and characters_list, and even calls out the repeat-use case (adding characters, re-authorizing).

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?

'Use again to add more characters or to re-authorize with more scopes' gives clear context for repeat invocation, and the scope presets imply when to pick 'full'. It stops short of explicit routing (e.g. 'call characters_list first to see already-authorized characters'), so no when-not 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 destructiveHint=true, the description discloses exactly what is destroyed: the SSO refresh token is revoked and the character entry is removed from this server. That is the key operational consequence an agent needs. It doesn't mention re-authentication requirements or irreversibility, which keeps 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?

Two short sentences, zero waste, with the destructive effect stated first and the usage constraint second. Nothing could be removed without losing 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 one-parameter destructive tool with a destructiveHint annotation and no output schema, the description covers effect, scope, and usage gate. Minor gaps (whether the user must re-authenticate, whether it is reversible) are not blocking 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?

Single parameter with 100% schema description coverage ('Character name or id'), so the schema already carries the semantics. The description adds no additional detail about accepted formats or name-vs-id resolution, which is the expected baseline when the schema does the work.

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 pair ('revokes the SSO refresh token... removes it from this server') for a named entity, which is clearly the inverse of character_login. It does not explicitly name a sibling, so it stops short of a 5, but an agent can distinguish it easily.

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?

'Only do this when the user asks' gives an explicit gating condition that prevents unsolicited logouts. It does not name alternatives (e.g. character_select to switch characters without removal), so it is clear context but not full when/when-not routing.

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 and openWorldHint, and the description adds genuinely non-obvious behavior: sections without scope are reported under 'unavailable' rather than failing, and clone-jump availability is included. That partial-failure contract is the key operational trait an agent needs, though permission/auth requirements are not spelled out.

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 'one-call snapshot' framing, then a dense but purposeful enumeration, closing with the failure-mode caveat. No filler sentences, though the long field list is a single breathless clause.

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, so the description carries the return-value burden itself and does so by enumerating every section and the 'unavailable' bucket. Combined with 100% schema coverage on the two inputs, an agent has everything needed to invoke and interpret it.

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. The description still adds value by mapping the section enum members to concrete content (e.g. 'fatigue' = jump fatigue, 'skills' = SP and what's training), clarifying what each section selection actually returns.

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 ('One-call snapshot of a character') and then enumerates the exact contents: corp/alliance, security status, online state, system/station, ship, wallet, SP, clones/implants, fatigue, loyalty points. This is unmistakably distinguishable from narrow siblings like character_skills or wallet.

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?

'One-call snapshot' plus the default-all-sections behavior makes clear this is the aggregate read to use when you want breadth in a single call, with the 'sections' param for narrowing. It stops short of explicitly naming alternatives (character_skills, wallet) that an agent could call instead for a single concern.

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 only declare idempotentHint=true; the description adds real value by disclosing the global side effect (affects all character tools) and repeat-call safety is implied by idempotency. It omits behavior on lookup failure, ambiguous partial-name matches, and whether selection persists across sessions.

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, front-loaded with the effect and followed by accepted input forms; nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, non-destructive context-setting tool with no output schema, this covers purpose, input forms, and blast radius. Only failure modes (unknown or ambiguous character) are left undiscussed.

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 would be 3, but the description adds meaning beyond the schema's 'Character name or id' by stating that a unique *part* of the name is accepted — a fuzzy-match rule an agent could not infer from the schema. The 'unique' qualifier also hints at ambiguity resolution.

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 (makes default) and resource scope ('all character tools'), which distinguishes it from character_login and character_logout by describing the effect rather than an auth action. It never explicitly says 'do this after login instead of character_login', so sibling differentiation is implied rather than stated.

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?

'Makes a logged-in character the default' implies a prerequisite (must be logged in) and an ordering (use before other character tools), which is useful context. However, it gives no explicit when-not guidance and never names character_login or characters_list as alternatives for discovering or authenticating a character.

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 openWorldHint=true, so safety is covered. The description adds useful details beyond them: skill results are keyed by name/group rather than ids, and the queue includes finish times. It does not address failure modes such as an unknown character name or a missing ESI scope, so this is incremental value, not rich behavioral context.

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, front-loaded with what is returned and followed by the one parameter worth explaining. Nothing is repeated from the schema and there is 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?

With no output schema, the description carries the burden of describing returns, and it does so concisely (grouping, names/levels, attributes, queue finish times) for a three-parameter read-only tool. A note on empty-result behavior or missing-scope errors would round it out.

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; the description earns an extra point by providing concrete example filter values that clarify substring matching across both skill name and group ('drone' matches a group, 'Gunnery' a skill). It does not restate the character or include_queue parameters, but the schema already handles those.

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 concrete resource (skill groups, attributes, training queue) and specifies the shape of the return ('names and levels, not ids'), which lets an agent distinguish it from most siblings. It does not explicitly differentiate itself from skill_check, which is the closest alternative, so it stops short of a 5.

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 positive guidance for the filter parameter with real examples ('Gunnery', 'drone', 'Caldari') and states the queue default, which implies when to use it. It offers no when-not conditions and never mentions skill_check as the alternative for a single-skill query, so usage is implied rather than fully scoped.

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 and openWorldHint, so safety is covered. The description adds genuinely new context: there is a notion of an 'active' character that silently applies to every other character tool, which is important behavioral knowledge an agent cannot get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with zero filler; the action comes first and the ordering advice ('call this first') is placed at the end where it is memorable.

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 parameters and no output schema, the description carries the burden of explaining return contents, which it does by listing active character, corporation/alliance, and scopes. It does not describe result structure or ordering, a minor remaining 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the schema or description to clarify further.

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 (lists) and resource (EVE characters authorized with this server) and enumerates the returned fields: active character, corporation/alliance, granted scopes. An agent can distinguish it from siblings like character_select or character_overview 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?

"Call this first when the user refers to a character by name" gives a clear trigger condition, and the note that the active character is used by default by all character tools clarifies downstream behavior. It stops short of naming explicit alternatives or when-not cases, so it is strong but not exhaustive.

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 readOnlyHint and openWorldHint. The description adds useful content-level detail (names for issuer/assignee/acceptor, locations, prices, courier details, items), but doesn't cover pagination, the include_items 25-contract cap, or result size behavior. It adds value beyond annotations without fully characterizing the response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense but efficient sentence that front-loads the resource and enumerates the returned fields without 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, so the description carries the return-content burden and does list the key contract fields. Missing details like default status=active and item-fetch cap are covered by the schema, but behavioral bounds on results are not described.

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 80%, so the schema already documents type, status, limit, character, and include_items. The description's mention of items in item-exchange/auction contracts lightly ties to include_items, but adds no syntax or default semantics beyond 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+resource: retrieves a character's contracts (issued to/by them). The parenthetical clarifies scope (issued to or by), and it enumerates the concrete data fields returned. It doesn't distinguish from siblings, though there is no direct contracts alternative here.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus alternatives, no prerequisites, no exclusions. The schema mentions the default active character and characters_list/character_select, but the description itself gives no usage 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?

Annotations provide only openWorldHint=true, so the description must carry nearly the full burden, and it does: it discloses that auth, compatibility date, caching and pagination are handled automatically, that id fields gain *_name siblings, and that non-GET methods mutate game state. It stops short of covering failure modes an agent would want here — ESI error-limit/backoff behavior, HTTP error surfacing, or what happens on a 404 route — which keeps it off 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?

Four sentences, each carrying distinct information (scope, placeholder substitution, handled plumbing, mutation warning), with the core purpose front-loaded and the safety warning last where it is most likely to be read before acting. Dense but not padded.

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 8-parameter, nested-object, open-world proxy tool with no output schema, the description covers the cross-cutting behaviors an agent cannot infer (auth injection, pagination, name enrichment, placeholder resolution, mutation risk). Nothing essential for a correct first call is left to guesswork.

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 75%, so most params are self-documented, but the description still adds real meaning the schema cannot: the {character_id}/{corporation_id}/{alliance_id} placeholders are auto-filled from the selected character, and authentication/pagination/name-resolution are applied automatically rather than per-call. It does not state the default for `method`, leaving the GET-vs-omitted behavior implicit.

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 capability — an arbitrary ESI route proxy — and explicitly frames it as an escape hatch for routes 'not covered by a dedicated tool,' which cleanly separates it from the many domain-specific siblings (assets, wallet, mail_list, etc.). An agent can decide between esi_request and any specialized tool 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?

It states exactly when to reach for this tool (uncovered ESI routes), points to the authoritative route catalog via URL, and gives a hard guardrail for the risky case: 'Non-GET methods change game state: confirm with the user first.' That is explicit when-to-use plus an explicit caution, which is the ceiling for this dimension.

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 openWorldHint=true, so safety and external-world behavior are covered. The description adds useful behavioral context: engine stats only appear when eve-fit is configured, and the tool does not persist anything.

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 return shape, then moves to the non-saving caveat. Despite being a single dense sentence, every clause adds useful scope or output information without redundant 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?

For a three-parameter analysis tool with full schema coverage and annotations, the description is complete enough: it explains input sources, the returned breakdown, the character/skill aspect, the eve-fit dependency, and the fact that nothing is saved. No output schema exists, and the description still summarizes the return value effectively.

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 parameters are already fully documented in the schema. The description does not add parameter-specific syntax or usage details beyond what the schema provides, making the baseline 3 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: it parses any EFT text and returns a rich fitting breakdown. It distinguishes itself from fitting_get by accepting arbitrary EFT input from sources like Pyfa or zKillboard, and from fitting_save by explicitly stating it does not save anything.

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 establishes the context for use: when the caller has EFT text from a user, Pyfa, zKillboard, etc., and wants the same breakdown as fitting_get without saving. It does not explicitly name fitting_get as the alternative for saved fittings or list exclusions, so it stops short of a full when/when-not routing guide.

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 openWorldHint=true, so the safety profile is known. The description adds useful context beyond that: deletion targets exactly one fitting, accepts an id or exact name, and is gated on an explicit user request. It stops short of stating irreversibility or behavior on ambiguous names.

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 short sentences with the primary action and identifier scope front-loaded, followed by the explicit-request guard. No wasted wording.

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 destructive delete with full schema coverage and destructiveHint annotation, the description provides the essential purpose and usage guard. It does not explicitly mention irreversibility or error behavior, but those are minor gaps given the annotations and low 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 the schema already documents both the fitting and character parameters. The description echoes 'by id or exact name' but adds no new meaning beyond the schema, which establishes the baseline of 3.

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: "Deletes one saved in-game fitting by id or exact name." This clearly distinguishes it from sibling tools like fitting_save, fitting_get, and fitting_analyze without needing to name them.

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 usage condition: "Only do this when the user explicitly asks." That is strong when-to-use guidance, but it does not mention alternatives or when-not scenarios beyond that single restriction.

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 and openWorldHint, so safety is covered. The description adds real behavioral context beyond that: the tool performs a skill check against a character (with missing skills and training time) and emits EFT/DNA exports, which tells the agent this call has character-dependent, import-ready side effects worth understanding before invoking.

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 sentence, front-loaded with the tool's purpose before the return-content list, so the reader can stop early. The content enumeration is long but each item is a distinct output category, so little is wasted; the only cost is that the sentence becomes a run-on dump.

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, so the description correctly carries the burden of describing the return payload in detail — modules, charges, CPU/PG usage, skill check, EFT, DNA. Missing only edge behavior such as unresolvable fitting names or what happens when skill check data is unavailable for the given character.

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% — all four parameters, including the enum for attributes and the default for check_skills, are documented in the schema. The description echoes 'by id, name or ship' but adds no syntax, format, or matching-behavior detail beyond what the schema already states (including substring matching and max 10 items).

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 (saved fittings) and scope ('Full detail'), and enumerates exactly which sub-objects are returned. It implicitly contrasts with fittings_list via 'full detail', but never names the sibling or explicitly delineates this from fitting_analyze/ship_fitting, so an agent must infer the routing.

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 'by id, name or ship' clause tells the agent what inputs are accepted, which is genuine usage guidance. However there is no explicit when-to-use, no when-not-to-use, and no pointer to fittings_list as the way to discover ids or to fitting_analyze for other purposes — usage is only implied.

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 supply only openWorldHint, so the description carries the disclosure burden and does it well. It reveals the required auth scope, a genuine data-loss behavior ('ESI cannot store charges per slot, so loaded charges are dropped (with a warning) unless they are also in the cargo section'), and the return value ('Returns the new fitting_id').

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?

Five short sentences, front-loaded with the action and scope, then the data-loss caveat, then the return value, then the confirmation prompt. No sentence is padding; each carries a distinct fact the agent needs before calling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and only a sparse annotation set, the description covers auth, mutation effect, a silent-data-loss edge case, the returned fitting_id, and a user-confirmation requirement. Nothing essential to calling this four-parameter write tool 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 75%, so most parameters are already documented. The description still adds semantic value the schema does not: that names inside the EFT text are 'resolved from static data' and that charge handling inside the `eft` blob has a caveat. It adds meaning rather than repeating 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 opens with a specific verb and resource: 'Saves an EFT fit to the character's in-game saved fittings.' It distinguishes itself from read-side siblings like fitting_get, fitting_list, and ship_fitting by being explicitly a persistence operation, and even names the exact ESI scope it maps to.

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 a clear prerequisite and behavioral gate: 'requires esi-fittings.write_fittings.v1' and 'Confirm with the user before saving.' It doesn't explicitly contrast itself with fitting_delete or say when not to use it, but the write intent and the confirmation requirement give an agent enough to route correctly.

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 and openWorldHint, so the safety profile is covered. The description adds a mild efficiency hint ('in the same call') that avoids N+1 EFT fetches, but says nothing about pagination, result limits, or what happens with a large fitting library.

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 core action and return shape. No filler, though the EFT sentence could be slightly tighter since the schema already states the default.

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 read-only list tool with no output schema, the description adequately conveys what comes back (ship names, module counts, optional EFT text) and that no parameters are required. Only pagination/volume behavior is left unaddressed.

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 parameters are fully documented structurally. The description reinforces the filter behavior (name or ship) and the EFT toggle's batching benefit, but adds no syntax or format detail beyond 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?

Clear verb+resource ('Lists a character's saved in-game fittings') with a concrete description of returned content (ship names and module counts). It does not explicitly distinguish itself from the sibling fitting_get, but the list-vs-single framing is implicit.

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?

Provides usage hints for its parameters ('Filter by fit name or ship', toggle include_eft), but never states when to prefer this over fitting_get or fitting_analyze, nor any prerequisites such as needing an active character.

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 openWorldHint=true, so the safety profile is covered. The description adds useful context by enumerating the returned fields, but omits behavior an agent would want: that delivered/cancelled jobs are excluded by default and that the call falls back to the active character.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with no filler, and the primary payload (what the tool returns) is front-loaded. It is a noun phrase rather than a verb-led statement, which slightly weakens scannability.

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?

Five optional parameters, all schema-documented, and the description lists the fields returned in place of an output schema, so an agent can call it correctly. Only minor gaps remain: default-exclusion of completed jobs and the active-character fallback are not surfaced in prose.

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 all five parameters (limit, include, character, blueprint_filter, include_completed_jobs) are already documented in the schema. The description only restates the blueprint name filter, adding no syntax or semantics beyond the schema, 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?

Names the resource (industry jobs / blueprints) and enumerates the fields each covers (activity, blueprint, product, runs, facility, time left; BPO/BPC, ME/TE, runs, location), so an agent knows exactly what data comes back. No other sibling deals with industry, so differentiation is implicit rather than stated, and there is no leading verb ('List/Get').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit statement of when to call this versus alternatives, and no prerequisites (e.g. that a character must be selected or that this requires the character to have industry jobs). A fragment ('Filter blueprints by name') is the only usage hint.

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 and openWorldHint, so safety is covered. The description adds behavioral context the annotations can't: skills are checked against the logged-in character with training time for gaps, and prices are optional/external. It does not disclose the cost of a batch call, caching, or how fuzzy name resolution behaves on a miss.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that leads with the core promise ('Everything about one or more items in one call') then enumerates the returned facets. The long comma list is dense but every element is a distinct capability an agent would want; nothing 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?

With no output schema, the description carries the burden of explaining return contents, and it does so thoroughly across eight facets including the character-dependent skill check. What remains missing is modest: how fuzzy matching failures surface and whether batching more than 10 is possible, but the essential contract is conveyed.

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 every parameter is already documented in the schema, making 3 the baseline. The description adds only light reinforcement by naming 'formatted attributes', required skills, variants and 'optionally Jita prices', which maps loosely to attributes, character and include_market without adding syntax or defaults.

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 concrete resource (items, singular or plural, by name or type id) and enumerates the specific payload it returns: category/group, meta level, volume, attributes, skills, variants, blueprint materials, market data. An agent can tell this is a deep single-item detail lookup rather than a search. It doesn't explicitly contrast with siblings like search_items or lookup, which keeps it from a 5.

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 is implied by the enumerated payload rather than stated: an agent infers this is the tool for full item detail. There is no explicit when-to-use/when-not guidance, no note that search_items should be used first to resolve fuzzy names, and no mention of the 10-item cap as a batching constraint (that lives only in the schema).

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 cover read-only and open-world behavior, so the description's job is to add context — and it does, disclosing that loss killmails (or any with include_fit) trigger EFT fit reconstruction with dropped/destroyed items, which is a non-obvious side effect. It omits pagination/recency-window behavior and any ESI rate-limit caveats.

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 dense sentences with zero filler, leading with the primary return payload and following with the conditional fit behavior. Nothing to cut.

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 correctly carries the burden of describing returned fields and the EFT payload shape. What remains thin is the filter/limit semantics, but for a read-only list tool the description is sufficient 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 coverage is 75%, so the baseline is 3. The description mostly restates the schema's own include_fit wording ('losses always include it') rather than clarifying the filter enum semantics or what 'recent' means for limit.

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 (recent killmails) and enumerates the returned fields (victim/attacker names, ships, system/security, zKillboard links), so the agent knows exactly what it gets. There is no sibling killmail tool to differentiate from, but the two-sentence scope is clear.

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 is only implied: the parenthetical 'For losses (or any kill with include_fit)' hints at how to obtain fits, and the schema's filter enum implies kill/loss selection. It never says when to prefer this tool or what happens if no character is supplied beyond the schema's default note.

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 and openWorldHint, so the safety profile is covered. The description adds genuine value by enumerating the kind of public details returned (corp/alliance of a character, ticker/members of a corp, security of a system), but says nothing about batching behavior, partial results, or failure when a name doesn't resolve.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the verb and scope first, then the entity list, then the detail payload. The long enumeration is justified because it defines the tool's domain, though the trailing '...' examples are slightly loose for a formal spec.

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 burden of describing the return shape; it sketches the detail fields but does not say how results are keyed (by id vs name) or how unmatched inputs are surfaced. Sufficient to attempt a call, insufficient to interpret the response confidently.

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% – ids, names, and details are all documented in the schema, including the 'default true' semantics of details. The description only loosely gestures at the details flag ('with public details') and adds nothing about the maxItems caps or exact-name matching beyond what the schema states. 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?

Uses a specific verb ('Resolves') plus an explicit enumeration of the resource classes (characters, corporations, alliances, factions, systems, regions, constellations, stations, items) and states that it maps a name or id to its counterpart. This is clearly distinguishable from siblings like search_items or system_info, though it never names an alternative directly.

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 bidirectional mapping (name→id / id→name) implies the usage scenario, but there is no explicit when-to-use guidance, no statement of when to prefer item_info / system_info instead, and no mention of batch limits or prerequisites. Adequate inference only.

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?

With readOnlyHint and openWorldHint already declared, the description adds genuine value: it discloses that only headers are returned (not bodies) and enumerates the header fields (sender/recipient names, labels, read state). It omits pagination behavior and the default-25 cap, which are left to the schema.

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, zero waste, with the return-content scoping front-loaded and the alternative named afterward. Every clause earns its place.

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 correctly carries the return-value burden by naming the header fields returned. Pagination and the limit default are left implicit, a minor gap for a read-only listing tool.

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 75%, just under the threshold where the schema alone suffices. The description adds no parameter guidance and does nothing to compensate for the undocumented unread_only flag, though label/limit/character are well described in 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 the specific resource (EVE mail) and scope (headers, recent) plus what each header contains, and explicitly routes body retrieval to mail_read. An agent can distinguish it from mail_read and mail_send 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?

'Use mail_read for bodies' names the alternative and the condition selecting it. No explicit when-not-to-use beyond that, but the header-vs-body split covers the main decision point.

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 openWorldHint=true, so the safety profile is covered. The description usefully adds that HTML is converted to plain text and that sender/recipient names accompany the body, but says nothing about the 10-mail batch ceiling, partial failures on invalid ids, or whether inaccessible mails are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence that front-loads the return payload and the HTML-to-text behavior. Nothing is padded, though a fragment rather than a verb-led statement makes it slightly less directive than it could be.

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 two-parameter read with no output schema, the description covers what comes back (full body, sender, recipients). The main gap is the batch-size limit and the exact response shape per mail, but the annotations and simple schema mean little else is needed.

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 only 50%: the character parameter is documented but mail_ids is bare. The phrase 'one or more mails' hints at the array/batch nature, yet the description does not disclose the max of 10 ids or that ids should come from mail_list, so it only marginally compensates.

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 the specific resource (mails) and scope (full text, one or more, with sender/recipient names), which clearly distinguishes it from the listing sibling mail_list and the write sibling mail_send. It never uses an explicit verb like 'retrieve', but the intent is 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?

Usage is only implied: fetching full bodies by mail id after using mail_list. The description names no alternative tool and gives no explicit when-to-use or when-not-to-use condition, leaving the agent to infer the mail_list → mail_read workflow.

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 only say openWorldHint=true and destructiveHint=false, so the description adds the crucial nuance that this dispatches a real, externally-visible message to other players and must be user-confirmed. It stops short of saying whether a sent mail can be recalled or what happens on an invalid recipient.

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 with zero padding; the core action comes first and the safety caution is front-loaded as a closing imperative rather than 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?

For a real-world-effect tool with no output schema and no annotations covering irreversibility, the description covers the essential behavioral risk and recipient semantics. It omits failure modes (invalid recipient, rate limiting) but is sufficient to call 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 75%, and the description compensates on the weakest field by explaining that recipients are character, corporation, alliance, or mailing-list names rather than raw IDs. The `character` parameter is left to the schema, which already documents its 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?

States a specific verb and resource ('Sends an in-game EVE mail from the character') and immediately disambiguates the recipient field semantics, distinguishing it clearly from read-side siblings like mail_list and mail_read.

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 precondition for use: 'always confirm recipients, subject and body with the user first.' It does not name alternatives, but the send-vs-read/list distinction is unambiguous from the purpose statement.

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 cover the read-only, open-world safety profile, and the description adds real context beyond them: the best-price/undercut comparison and the magnitude of the gap, plus escrow being reported. It stops short of stating cost/latency of the competition check other than what the schema notes, but the added behavioral detail 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?

A single front-loaded sentence that leads with the primary payload and appends the optional history mode, with no filler. Slightly dense with em-dash clauses, but 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?

No output schema exists, yet the description enumerates the returned fields precisely (names, remaining volume, expiry, escrow, competition status) and flags the optional history. Combined with fully-documented parameters and safety annotations, an agent has everything needed 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 coverage is 100%, so all three parameters are already documented in structured form, establishing the baseline of 3. The description hints at what include_history and check_competition do ('recent order history', 'best price... or undercut') but adds no formatting or defaults 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 resource (a character's open market orders) and enumerates the payload — item/location names, remaining volume, expiry, escrow — plus derived undercut/outbid status. An agent can distinguish this from market_prices (price lookups) and assets (owned stock) from the content alone, though no sibling is named explicitly.

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 is implied by the content description — you'd call this to see your own open sell/buy orders. The optional history and competition modes are mentioned, but there is no explicit 'use this instead of X when Y' routing against market_prices, wallet, or assets, and no stated prerequisites beyond the schema's pointer to character_select.

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?

readOnlyHint=true and openWorldHint=true already tell the agent this is a safe external read, so the description's job is lighter. It adds the default location and the history/depth defaults, but says nothing about rate limits, data freshness, or failure behavior for unknown item names or structures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that leads with the returned data and then the configuration options. The parenthetical location list is long but informative; nothing is redundant enough to cut.

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 usefully enumerates the return fields (best buy/sell, spread, order counts, volumes, optional history and depth) and covers the 20-item cap and defaults. Only minor gaps remain, e.g. item-name fuzzy matching nuance and behavior for invalid locations.

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. The description still earns extra credit for 'location' by explaining it accepts not just city names but 'any region/system/station name, or a structure id' — meaning the schema's terse 'Market location' string does not convey.

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 (market prices) and enumerates exactly what is returned: best buy/sell, spread, order counts, volumes. An agent can tell it apart from wallet/market_orders in practice, but the description never names a sibling or explicitly excludes anything, so it falls short of a 5.

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 implied by the defaults and location options ('default Jita 4-4', history default true), but there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as market_orders or appraise for related pricing work.

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 and openWorldHint, so the safety profile is covered. The description adds genuine value by noting the YAML payload is parsed and ids are resolved to names, and 'Recent' implies ordering, but it says nothing about pagination behavior past the limit cap or how unread_only interacts with the result set.

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, zero padding, with the resource definition and its payload-processing behavior front-loaded and the filtering hint placed last. Every sentence carries information an agent would not get from the schema or annotations.

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 usefully characterizes the return shape as parsed YAML with resolved names, which is the key unknown for this tool. It does not describe the ordering guarantee or what the unread state looks like in results, leaving a small gap for a feed-style tool.

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 75%, which sets a baseline of 3. The description adds useful semantics for type_filter by giving concrete substring examples ('Structure', 'War', 'Kill'), but the undocumented unread_only flag and the limit/character defaults are left entirely 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?

Names the resource precisely (recent in-game notifications) and enumerates the concrete content types it returns (structure attacks, war declarations, kill reports, sov, corp applications), which lets an agent distinguish it from mail_list and killmails. It stops short of explicitly contrasting itself with those adjacent tools, so it is clear but not maximally differentiating.

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 is implied through the type_filter guidance ('Filter by type substring (e.g. Structure, War, Kill)'), which shows how to narrow results. However, there is no statement of when to prefer this tool over killmails or mail_list, nor any exclusion or 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 cover read-only and open-world behavior, and the description adds a valuable freshness caveat: ESI only updates PI data when the colony is viewed in game. It also notes that extractor expiry times are ordered soonest first, which helps interpretation. It does not cover auth requirements or rate limits, but annotations already establish the safety profile.

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 written sentences front-load the returned data and then add the important freshness caveat. There is no redundant or filler 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?

With no output schema, the description effectively serves as a return-value summary by enumerating colony names, types, extractor products, expiry ordering, schematics, and storage. Combined with the fully documented input schema and annotations, it gives an agent enough information to call the tool 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 both parameters are fully documented in the schema. The description only implies the `character` parameter and storage contents without adding format details or defaults beyond what the schema already provides. Baseline 3 is appropriate when the schema does 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?

The description clearly identifies the resource as a character's PI colonies and enumerates the returned contents (planet names/types, extractors, expiry times, schematics, storage). It is specific, but it does not explicitly distinguish this tool from the broader sibling `industry` tool.

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 does not state when to use this tool instead of alternatives such as `industry` or `assets`, nor does it provide when-not-to-use guidance. The ESI update caveat is useful context, but it is not usage routing.

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?

With only openWorldHint=true in annotations, the description carries most of the behavioral disclosure. It usefully reveals that the tool returns route systems with security and kill data and that it can optionally mutate the in-game autopilot destination, though it does not discuss permissions or side-effect reversibility beyond the schema's scope note.

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 three tight sentences with the core purpose and return data front-loaded, followed by default behavior and the optional autopilot side effect. No sentence is wasted.

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 summarizes the return contents well enough for an agent to understand what comes back. Parameter semantics are covered by the schema, and the optional autopilot side effect is disclosed, though usage guidance remains thin.

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 all parameters are already documented in the input schema. The description adds only that origin defaults to the character's current system and that set_destination is optional, which is useful but largely duplicative of 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: 'Plans a stargate route,' and details the returned data including systems, security, region, breakdown, and recent kills. It is clear what the tool does, but it does not explicitly differentiate itself from nearby siblings such as ui_action for waypoint setting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It mentions origin defaults and optional autopilot setting, but these are operational details rather than guidance on selecting this tool over another.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior: fuzzy matching semantics, acceptance of common shorthand (mwd, scram, web), and the default hiding of Blueprints/SKINs — none of which appear in the schema.

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, each carrying distinct information: scope, multi-query/shorthand support, hidden item classes, and the sibling handoff. No filler and the core purpose is front-loaded.

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 could briefly note the shape of results (per-query match lists bounded by limit). Still, combined with full schema coverage and explicit sibling handoff, an agent has enough 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 every parameter (group, category, meta_group, limit, with_prices, queries) is already documented. The description only reinforces that multiple queries and shorthand are accepted; it adds no filter semantics beyond the schema, 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: 'Fuzzy search over every published EVE item', with concrete examples (ships, modules, ammo). It immediately distinguishes itself from item_info by scope, so an agent knows this finds matches while item_info details them.

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 to item_info for 'full details on a match' and notes Blueprints/SKINs are hidden unless asked. Usage is clear, though it doesn't spell out when NOT to use it (e.g., exact-ID lookup) or which sibling handles market/appraisal needs.

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 openWorldHint=true, covering the safety profile. The description adds useful return-content detail about server and SDE build data, but does not discuss freshness, rate limits, authentication, or response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence that lists the key returned values without filler. Every phrase contributes to identifying the resource and its contents.

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-parameter, read-only status tool with no output schema, the description covers the main returned data fields and is largely sufficient. It could be slightly stronger by mentioning response structure or data freshness, but no critical invocation detail 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?

This tool has zero input parameters, so there is no parameter semantics for the description to clarify. The baseline score of 4 applies because the schema is effectively complete with an empty object.

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 resource, EVE server status, and enumerates what it returns: players online, version, start time, and SDE build. It does not explicitly distinguish this from related siblings such as system_info, so it falls short of a 5.

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 explains what the tool returns but gives no guidance on when to use it versus alternatives like system_info or esi_request. There are no exclusions, prerequisites, or context cues for selecting 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a real behavioral trait agents must know: ESI caches assets for up to an hour so recent refits may be stale. It also enumerates what the payload contains. It does not discuss auth requirements or failure modes, 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?

Two sentences, both front-loaded: the first gives purpose, scope and output shape, the second gives the ESI cache caveat. No filler and nothing 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?

No output schema exists, so the description carries the return-value burden and does so by listing the concrete payload sections (modules/charges, drones, cargo, resources, attributes, skill check, EFT, DNA). Combined with the caching caveat, an agent has everything needed to call and interpret it.

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 all four parameters are already documented in structured fields, including the 'current' default and the attributes enum. The description adds only the in-line restatement of the own-ship default, no extra syntax or format 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?

States a specific verb and resource ('Reads how a real ship ... is fitted'), defines the default target (the ship they are flying), and explicitly contrasts itself with fitting_get by saying the output mirrors that tool but is sourced from actual assets. An agent can distinguish it from fittings_list/fitting_get 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 conveys clear context: use this when you want the real, undocked fitted state of a ship the character owns, with a documented default of 'current'. It stops short of a full routing rule (it never says 'for saved fits use fitting_get instead'), so the alternative is implied by the shared-output note rather than 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?

With no output schema, the description carries the burden of explaining results and does so well: prerequisite skills, missing levels, SP required, estimated training time derived from character attributes, and a training order. Annotations already cover the read-only and open-world nature, so remaining value is in the output content, which is covered.

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, front-loaded with the core check and followed by the result contents. No filler; slightly dense but 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?

Covers all three parameters and the return content in the absence of an output schema. One minor gap: with zero required parameters, it does not say what happens if neither eft nor items is supplied, nor what takes precedence if both are.

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 eft, items, and characters. The description only restates the shapes (items or a whole fit, compare several characters) without adding format, limit, or precedence details 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 (checks) and resource (items or an EFT fit) and enumerates the item categories covered (ships, modules, ammo, drones). It is clearly distinct from character_skills in spirit, but the description never names or contrasts a sibling, so sibling differentiation is left implicit.

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 clear context: use it to validate items or a whole fit, and to compare several characters in one call. There are no explicit when-not conditions or named alternatives, but the intended usage 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?

Annotations already declare readOnlyHint and openWorldHint, so the description only needs to add domain context — and it does, notably the data-freshness window (kills and jumps "in the last hour") and the K-space vs J-space response split. It omits what happens for an unknown system name or whether the lookup is cached/live.

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, front-loaded with the resource and its payload, then branching to the J-space case. The field enumeration is dense but each clause maps to a real returned field, with 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?

With no output schema, the description must outline the return shape, and it does so for both normal and wormhole systems. It is slightly thin on edge cases (invalid/ambiguous system names, the role of the optional character param), but broadly sufficient to call 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% with clear field descriptions and one required param, so the baseline of 3 applies. The description's note about 'current' merely repeats the schema's own wording for `system` and adds nothing about the `character` 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?

Names the resource (a solar system) and enumerates the exact data returned: security, constellation/region, NPC stations, gate neighbours, sovereignty, activity stats, trade-hub distances, plus a distinct J-space branch. Nothing in the sibling list (lookup, route_plan, killmails, wormhole_type) returns this bundle, so an agent can separate it 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?

The only routing guidance is "Use 'current' for the character's location", which is a parameter hint rather than a when-to-use rule. It never says when to prefer this over lookup, route_plan or killmails, so usage is implied by the content list rather than 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?

With only openWorldHint in annotations, the description adds useful behavioral context: it acts on a running client, requires an in-game login, and performs side-effecting UI actions such as setting autopilot or opening windows. It does not cover failure modes, reversibility, or rate limits, but it meaningfully supplements the sparse 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?

The description is a single front-loaded sentence with no filler. Each clause corresponds to a supported action, so the length is justified by the need to enumerate the action set.

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 UI-control tool with no output schema and minimal annotations, the description covers the key prerequisites and action semantics an agent needs to invoke it. It leaves some gaps around result behavior and failure handling, but those are secondary for selecting and calling the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description maps action values to target types, for example waypoint targets as system/NPC station/structure and open_info targets as item/character/corporation/alliance. This adds semantic meaning beyond the schema's generic target description. It does not explain the optional character parameter, but the schema already documents that 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: it acts on the running EVE client. It enumerates the four supported UI actions, making the tool's purpose clear. It does not explicitly distinguish itself from siblings such as route_plan or item_info, but its UI-control nature is distinctive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an important prerequisite: the character must be logged in to the game. It lists the action choices, which implies usage contexts. However, it does not explicitly say when to prefer this over alternatives like route_plan for routing or lookup/item_info for data retrieval.

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 and openWorldHint, so the safety profile is covered. The description adds useful substance by naming the returned fields (party names, item/quantity/price/location/counterparty), but says nothing about defaults, the 30-day ESI retention limit, empty-result behavior, or volume of data returned.

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 sentence, front-loaded with the headline output (ISK balance) and then the sub-sections. Dense parenthetical field lists are efficient rather than wasteful, though the single long sentence is at the edge of 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?

With no output schema, the description carries the return-value burden and does so reasonably by enumerating the four result sections and key fields. Combined with the fully documented schema and read-only annotation, an agent has enough to call it correctly; only defaults/retention nuance is left 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 description coverage is 100% and each parameter is well documented in-schema, so baseline is 3. The description only implicitly links 'recent days' to the days parameter and lists journal/transaction sections; it adds no syntax or constraint detail beyond the schema, and never mentions the character 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 concrete resource (ISK balance, income/expense breakdown, journal entries, market transactions) with specific content enumerated. It is clearly distinguishable from most siblings, but makes no attempt to differentiate from adjacent tools such as market_orders, assets, or contracts, which also touch financial/inventory data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never states when to call this versus alternatives like market_orders or contracts, nor any prerequisites (e.g., character selection, ESI scope or auth). Usage is only inferable from the list of returned data.

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 and openWorldHint, so safety is covered. The description goes further by disclosing the return payload (destination class, max/total mass, regeneration, lifetime, static classes), which matters because there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence: verb and input first, then the returned field list. Every clause carries information and nothing is repeated from structured fields verbatim.

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 one simple read-only parameter and no output schema, the description supplies the missing return-value detail, which is the main completeness risk here. It stops short of noting behavior for unknown codes or the 20-item cap, but the schema handles the cap.

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's schema entry already includes an example array. The description restates example codes but adds no format rules, case sensitivity, or batch behavior beyond the schema, 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?

Specific verb (looks up) plus resource (wormhole types) and the exact key (signature code) with concrete examples K162, H296, D845. It also enumerates the payload, so an agent knows precisely what comes back and that no sibling tool offers this data.

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 is implied by the description — call it when you have a wormhole signature code — but there is no explicit when-to-use/when-not statement or named alternative. In this toolset there is no direct competitor, so the gap is minor but real.

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