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

No annotations are provided, so the description carries full burden. It details the authentication flow (SIWE in EVM, URL approve in AGW), token storage, automatic subsequent tool behavior, and force parameter's effect. This is rich behavioral context beyond a simple 'authenticate'.

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 efficiently structured with a one-sentence purpose, usage condition, mode behaviors, and force explanation. No filler; each sentence adds value.

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

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

Given the tool's simplicity (one optional param, no output schema) and abundance of sibling tools, the description adequately covers purpose, usage triggers, mode-specific behaviors, and edge cases. It is a complete standalone explanation.

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 sole parameter `force` is already described in schema, but the description adds a concrete scenario ('after the game server was reset and the stored token references a stale user'), enhancing understanding beyond schema coverage.

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 states 'Create a blockchain session' as the core function, using a specific verb and resource. It distinguishes itself from sibling tools by focusing on authentication/session setup rather than game actions.

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 instructs 'Call this tool when other tools fail with authentication or session errors', providing clear when-to-use guidance. Also clarifies force=true usage for stale sessions, and mentions both EVM and AGW modes.

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 annotations, the description carries full weight. It discloses costs ($CPU, possibly refined resources), auto-approval of spend, on-chain placement, waiting for confirmation, build time delay, single-building-per-cell rule, safe no-op on re-run, and demolition cooldown. This is rich behavioral context beyond what the schema conveys.

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 dense but every sentence earns its place, covering prerequisites, catalog, costs, timing, post-actions, and constraints. It is longer than typical but appropriate for a complex blockchain interaction; structure flows logically from placement to follow-up.

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 no output schema and no annotations, the description covers the full lifecycle: authentication, building type selection, costs, waiting, activation, replacement, cooldown, and inspection. It even mentions the no-op case. No obvious gaps remain for an agent to invoke this tool successfully.

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% for both tokenId and buildingType, so the baseline is 3. The description adds meaning by categorizing buildingType (extractor, crafter, hub) and linking it to the game config and subsequent actions, which goes beyond the schema's enum list. It does not add new syntax for tokenId but reinforces the 'own' requirement.

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+resource: 'Place a building on a revealed Land cell you own', clearly distinguishing it from sibling tools like cpu_demolish and cpu_start_mining. It also enumerates building categories (extractor, crafter, hub), making the tool's function unmistakable.

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 provides explicit context: requires a session (cpu_authenticate first), references the catalog (cpu_get_game_config) for choosing buildingType, and explains follow-up actions (cpu_start_mining for extractors, cpu_craft for crafters). It also warns about the need to demolish before switching buildings and the cooldown after demolition, giving clear when-to-use and when-not-to 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?

Since no annotations are provided, the description carries full burden. It discloses all key behavioral traits: atomic tx, cost components (price, transit fee, gas), auto-approval with 10% headroom, delivery timing, and permission to buy own lot. No contradictions.

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 detailed but each sentence adds value. It is front-loaded with the main action and then explains nuances. Could be slightly more concise, but overall well structured.

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

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

Given no output schema, the description covers prerequisites, process, cost preview, auto-approval, delivery, and finalization. It mentions the returned deliveryId. Lacks explicit error conditions but is adequate for a buy 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 100%, so baseline is 3. The description adds significant value: for 'chain' it explains waypoint structure and scouting via cpu_next_hops; for 'lotId' and 'value' it provides context on sources and constraints (positive integer, ≤ remaining).

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 states the verb ('Buy'), resource ('units from an OPEN lot'), and outcome ('delivered to your own cell'). It distinguishes from sibling tools like cpu_quote_buy (preview) and cpu_create_lot (create).

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 explicit context: when to buy (from open lot), prerequisite (needs session), and related tools (cpu_quote_buy for preview, cpu_finalize_delivery for completion). However, it doesn't explicitly state when not to use (e.g., if lot is closed).

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?

Given no annotations, the description carries full burden and excels: it discloses the atomicity of the transaction, potential $CPU transit fee for foreign hub returns, gas costs, and the need to call cpu_finalize_delivery for crediting. It also clarifies that no crediting occurs until arrival, which is a key behavioral trait.

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 yet information-dense, front-loading the purpose and then covering requirements, fees, and post-steps without redundancy. Each sentence adds value, and the structure is logical.

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 tool with no output schema, the description manages to cover prerequisites, process, fees, and next steps (finalize_delivery, tracking). It even implies the return of a deliveryId. It is complete enough for an agent to understand the workflow and necessary actions.

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% for both params. The description restates the chain format and lotId ownership, adding little beyond the schema. While it mentions the fee implication, that's more behavioral transparency than parameter meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Withdraw an OPEN lot; the unsold units return to you, on-chain.' This is a specific verb+resource that distinguishes it from sibling tools like creating or buying lots. The on-chain detail adds precision.

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 provides clear context: requires a session, requires chain for the return shipment, and mentions tracking with cpu_list_my_lots/cpu_get_lot. However, it does not explicitly state when not to use this tool or name alternatives, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly describes side effects: banking into resource balance, freeing a slot when fully claimed, no-op success when nothing is matured, and errors when no craft processes exist. This is exceptional transparency for a state-changing tool.

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

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

The description is four sentences, each earning its place: action, prerequisite, edge cases, and complementary tool. It is front-loaded with the core purpose and avoids any filler or repetition.

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

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

Given the tool's complexity (a claim operation with error cases, side effects, and prerequisites) and the absence of annotations and output schema, the description covers all essential context. It tells the agent about authentication, when the operation succeeds or fails, and what to check before calling, making it fully self-contained.

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

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

The schema description for tokenId already states 'The tokenId of the cell whose craft processes to act on.' The description adds the ownership constraint ('a cell you own') and clarifies the action's context, which goes slightly beyond the schema. However, the schema coverage is high, so the additional value is modest.

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: 'Bank every matured craft batch on a cell you own into its resource balance.' This clearly states the action and its subject, distinguishing it from related tools like cpu_craft (creating batches) and cpu_get_craft_status (viewing status). It leaves no ambiguity about what the tool accomplishes.

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 provides explicit usage context: it requires prior authentication ('Requires a session — call cpu_authenticate first'), recommends checking claimable items first ('Check what is claimable first with cpu_get_craft_status'), and documents edge cases for when it is a no-op or an error. This tells the agent exactly when and how to use the 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?

Given no annotations, the description carries the full burden and does so thoroughly. It discloses edge cases (no-op, error), cycle semantics (only whole cycles settle, wait resets if output doesn't fit), side effects (does not stop running job, retires completed jobs and frees process slot). This is exemplary behavioral transparency.

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

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

The description is front-loaded with purpose, then prerequisites, then edge cases. Every sentence provides non-redundant, necessary detail. Despite being longer than typical descriptions, it is dense with useful information and avoids fluff.

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 and no annotations, the description thoroughly covers prerequisites, side effects, and edge cases. It could explicitly mention the return value (e.g., new balance) to be fully complete, but the behavioral detail and pointer to cpu_get_mining_status make it nearly comprehensive.

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

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

The schema covers 100% of the single parameter (tokenId) with a description that already includes 'a cell you own with an extractor'. The tool description adds no additional param semantics beyond restating the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('bank') and resource ('matured mining cycle an extractor has produced on a cell you own'), clearly distinguishing it from siblings like cpu_get_mining_status (checking status) and cpu_start_mining (starting mining). It unambiguously states the action and its target.

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 explicitly states a prerequisite ('Requires a session — call cpu_authenticate first') and advises checking availability with cpu_get_mining_status. It also differentiates valid claim scenarios (harmless no-op when nothing new, error on cells without an extractor), providing clear when-to-use guidance.

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

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

With no annotations provided, the description carries full burden. It discloses key behaviors: inputs are debited upfront for all batches, most recipes start timer immediately, forge_wcpu requires on-chain payment and one-time allowance, and the run stops itself with no cancel. This is thorough for a mutation tool.

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

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

The description is well-structured and front-loaded with the main action. Every sentence adds value without redundancy. It is slightly long but efficient for the complexity of the tool.

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?

The tool has no output schema, so the description should ideally mention what it returns (e.g., a craft ID or status). It only hints at follow-up tools. Error conditions or limitations beyond 'no cancel' are omitted. For a tool with three parameters and no output schema, some gaps remain.

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 baseline is 3. The description adds value by explaining behavioral context for parameters (e.g., 'batches' debited upfront and no cancel, 'recipeId' with special forge_wcpu cost). This goes beyond the schema's property descriptions.

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 states the main action: 'Run a craft recipe on a cell you own (refine raw resources, or forge $WCPU).' It uses specific verbs and resources and distinguishes from sibling tools like cpu_list_recipes, cpu_get_craft_status, and cpu_claim_craft.

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 provides clear guidance: prerequisites ('call cpu_authenticate first'), discovery information ('discover recipes with cpu_list_recipes'), and follow-up tools ('cpu_get_craft_status' and 'cpu_claim_craft'). It also explains special cases like forge_wcpu costing $CPU. However, it does not explicitly state when not to use this tool.

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

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

No annotations are provided, so the description carries full burden. It thoroughly discloses behavioral traits: atomic transaction, shipping goods, opening lot, gas costs, transit fees, sale fee freezing, delivery state, and return values. It also explains edge cases like rate raises and maxSaleFeePercent behavior.

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 relatively long but well-structured. It front-loads the main purpose and prerequisite, then details parameters and behavior. Every sentence adds value, but there is slight redundancy (e.g., mentioning tracking tools twice). Still, it is concise given the complexity.

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

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

Given the complexity (5 parameters, no output schema), the description is remarkably complete. It covers prerequisites, parameter semantics, process flow, edge cases (rate raises), and return values (lotId, saleFeePercent). It also mentions subsequent tracking tools, making it fully actionable.

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 baseline is 3. The description adds significant meaning beyond the schema: it explains the chain structure (first node source, last hub), value as 'units to list', resourceId needing balance, pricePerUnit must be >0, and maxSaleFeePercent's effect. This elevates the score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: 'List units of a resource for sale at a Hub, on-chain'. It uses a specific verb (list) and resource (units of a resource) and distinguishes this from sibling tools like cpu_buy_lot and cpu_cancel_lot.

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 explicitly states the prerequisite: 'needs a session — cpu_authenticate first'. It also explains when to use the chain parameter and provides guidance on optional maxSaleFeePercent. However, it does not explicitly state when not to use the tool, though it is 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?

Given no annotations, the description fully discloses behavioral traits: it consumes resources (CPU and materials), preserves deposits and warehouse balances, and imposes a cooldown. It also explains restrictions and references other tools for exact costs.

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 well-structured and front-loaded with the main purpose. While slightly verbose, every sentence contributes necessary context. It balances detail with clarity.

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?

The description is comprehensive, covering prerequisites, costs, restrictions, and outcomes. No output schema exists, but the description adequately explains what the tool does without needing to detail return values.

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 only parameter, tokenId, is described identically in both the schema and the description. With 100% schema coverage, the description adds no additional meaning beyond what the schema already provides, warranting a baseline score 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?

The description clearly states the action: 'Remove the building from a Land cell you own, clearing it for a different building.' This is a specific verb+resource combination, and it effectively distinguishes the tool from siblings like cpu_build or cpu_buy_lot.

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 explicitly provides prerequisites ('Requires a session — call cpu_authenticate first'), costs, and conditions for use (no active mining or craft process, specific rules for mining extractor and hub). It also references alternatives like cpu_get_game_config for details.

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

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

With no annotations, the description discloses key behavioral traits: permissionless access, on-chain execution with gas costs, time-gating constraint, and the need for a session. This goes beyond basic shorthand and helps the agent reason about side effects and prerequisites.

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 well-structured: what it does, key constraints, and prerequisite steps. Every sentence earns its place with no redundancy.

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

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

For a single-parameter tool with no output schema and no annotations, the description covers purpose, eligibility, permissions, gas costs, and session setup. It is complete enough for an agent to decide when and how to invoke 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% and the parameter description already explains 'on-chain delivery ids' and reference to list_my_transports. The tool description reinforces this but adds no new semantic detail beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource pair: 'Finalize one or more arrived deliveries' and explains the effect 'crediting each to its target cell'. This clearly distinguishes it from sibling tools like cpu_transport or cpu_claim_craft.

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 states the precondition that a delivery can only be finalized after arrival time and points to cpu_list_my_transports for identifying ready_to_finalize deliveries. It also notes the session requirement and mentions cpu_authenticate, providing a clear workflow. It does not explicitly exclude other tools but offers sufficient 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?

With no annotations, the description carries full burden. It discloses that items are descriptive ('suggest no action'), scouting is read-only, authentication needed for own cells, and potential unavailability of deliveries. It details flags and severity levels comprehensively.

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 dense but well-structured, starting with purpose then detailing flags and usage. While packed with information, some sentences are long; slight trimming could improve conciseness.

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

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

Given no output schema, the description adequately describes return items (flags with severity, descriptive objects). It covers edge cases like deliveries down. The tool's complexity is well-handled.

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%, baseline 3. The description adds meaning: owner parameter scope (own vs scout) and minSeverity as urgency filter. It provides context beyond the schema's basic descriptions.

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 states what the tool does: 'Owner-scoped roll-up of cells worth attention, most time-sensitive first'. It distinguishes itself from siblings like cpu_get_cell or cpu_get_map by focusing on attention-worthy items.

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 explains when to use ('so you skip scanning the whole map') and covers scoping (own cells vs scout another). It provides a note about deliveries endpoint downtime. However, it doesn't explicitly state when not to use the 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?

Without annotations, the description discloses that the tool requires a configured wallet, clarifies that no session is needed, and describes the output as human-readable decimals. It doesn't cover potential errors if wallet is missing, but the key behavioral traits are stated.

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, front-loaded sentences. Every sentence adds value: what it shows, when to use it, and what it requires. No redundancy.

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

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

For a simple read-only balance query with no parameters and no output schema, the description covers purpose, usage timing, output format, and prerequisites. It is entirely adequate.

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, and the schema confirms this. The description has no need to explain parameters, and the baseline of 4 applies due to no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it shows the wallet's spendable funds, distinguishing CPU currency from native gas balance. The verb 'Show' and the explicit list of what it includes make the purpose 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?

Explicitly instructs to check before paid actions to avoid failed or stranded payments, providing both when and why. It also notes the prerequisite of a configured wallet, which helps the agent decide when it can call 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?

The description goes into depth about behavior: returns the cell, neighbours expanded as full cell states, distanceFromMine with BFS steps and null conditions, plus storage box contents and the stalled flag's precise trigger and effect on production. With no annotations present, this detailed disclosure fully carries the transparency burden.

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 uses four sentences, each with a distinct job: purpose, return structure, field semantics, and a pointer to a sibling tool. No filler or redundancy; every sentence 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?

In the absence of an output schema, the description details the major return components and edge cases: neighbour expansion, distanceFromMine with null and 50-step limits, storage box fields, and the stalled flag behavior. This is comprehensive and actionable for a complex inspection 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 100% — the only parameter tokenId is fully described with type, range, and purpose. The description adds contextual info ('any owner — the map is public') but no additional parameter syntax or format details, so the baseline of 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?

The description opens with a specific verb and resource: 'Inspect one cell in depth,' clearly stating the tool's action and target. It differentiates from siblings by explicitly pointing to cpu_get_map for broader awareness, making its narrow, deep-dive scope unmistakable.

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

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

It explicitly names an alternative tool: 'For broader situational awareness use cpu_get_map,' giving the agent a clear when-to-use versus when-to-use-something-else decision. It also notes that any owner's cell can be inspected since the map is public, setting expectations for access.

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 annotations provided, the description fully carries the behavioral transparency burden. It discloses key stateful behavior: the reply carries a new version for subsequent calls, the server.reachable flag indicates API availability, and it explains the implications of false (actions will fail) and the reconnection policy. This goes well beyond the bare minimum.

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?

Though relatively long, every sentence earns its place: it opens with the purpose, then explains the parameter usage, and then covers the important server.reachable edge case. The structure is logical and front-loaded, with no redundant fluff or repetition.

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

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

The description is sufficiently complete for the tool's complexity. It explains the versioning mechanism, the meaning of the server.reachable flag, and the recommended polling behavior, even covering the post-outage recovery step. While there is no output schema, the description highlights the critical return fields and their roles, making the tool easy to invoke and interpret.

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

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

The schema already fully documents the single parameter sinceVersion, including its type, default, and meaning ('Omit or 0 to return every cell'). The description adds no new semantic information beyond what the schema provides—it simply restates the same concept in prose. Therefore the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's function: 'Get only the cells that changed since a given version'—a specific verb with a clear resource and scope. It also distinguishes itself from related tools by framing it as a way to 'react to other players without re-reading the whole map', clearly differentiating from full-map retrieval tools like cpu_get_map.

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 provides explicit usage context: use it to avoid re-reading the whole map, pass the version from a previous response, and omit sinceVersion for a full snapshot. It also gives direct guidance for the unreachable case ('keep polling cpu_get_changes rather than retrying actions') and after an outage ('call once with sinceVersion 0 for the full picture'), effectively steering the agent away from alternatives.

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 annotations, the description carries full burden and does so richly: explains stalling condition (output box has room for less than one whole batch), settlement behavior (batches settle whole or not at all), reset behavior, meaning of isFinished, process slot hold, and timestamp convention. This exceeds typical status-read transparency.

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 dense yet well-organized, front-loading the core output then progressing to stall behavior, isFinished semantics, timestamp note, and final guidance. Every sentence contributes unique information; no filler or redundancy.

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

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

No output schema exists, so description must explain return values; it does so by naming fields (completedBatches, batches, blockedResourceIds, isFinished, serverTime) and their semantics. Given the complexity of craft state, the description covers causes, effects, actions, and timing comprehensively.

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 already covers tokenId with a clear description (100% coverage), so baseline is 3. Description adds meaningful context by confirming the operation works for any tokenId ('Public'), removing ambiguity about ownership restrictions, and tying tokenId to the cell context. This slight elevation above baseline is justified.

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?

Description uses specific verb 'Get' with a clear resource 'craft job on a cell' and enumerates the returned details (recipe, status, progress, claimable amounts, timings). It distinguishes itself from sibling status tools like cpu_get_mining_status and cpu_get_transport_status by focusing on craft state.

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?

States when to use: 'This is the source of craft progress' and explicitly directs to the next action: 'bank matured batches with cpu_claim_craft'. Also notes 'Public — works for any tokenId', clarifying access constraints. Provides clear context for interpretation of stalled states and recovery actions.

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?

No annotations provided, but description discloses it's a read-only operation ('free reference read') and indicates no session/auth needed. Could mention if any other side effects exist, but current disclosure is sufficient.

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 purpose, no wasted words. Efficiently communicates necessary information.

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

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

Given no output schema, the description comprehensively covers return values (resource catalog, building catalog, reveal-cost params, addresses, recipe count) and points to sibling for full recipes.

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?

No parameters exist (schema coverage 100%), so baseline 4 applies. Description adds value by detailing the return contents beyond 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 clearly states 'Return the game rulebook for the active network' and enumerates specific components (resource catalog, building catalog, etc.), distinguishing it from sibling tools like cpu_list_recipes.

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

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

Explicitly says 'A free reference read — call it once to ground planning. No session needed.' and directs to cpu_list_recipes for full recipe graph, providing clear when/alternative guidance.

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

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

With no annotations, the description carries the full burden. It explicitly labels the operation as 'Public read', disclosing it's safe and requires no authentication. It also outlines the exact data returned, giving transparency into behavior beyond basic semantics.

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, well-structured sentence that front-loads the action and resource, then efficiently lists the returned fields. No wasted words.

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 get-with-ID tool, the description is complete: it states the action, the access level (public read), and the full set of returned attributes without relying on an output schema. It covers the essential context needed to invoke 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 the single parameter lotId described as 'The lot id to inspect.' The description's 'by id' mirrors this and adds no new parameter-specific meaning beyond what the schema provides, so 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?

Description uses specific verb 'Inspect' and resource 'single lot by id', clearly distinguishing from sibling listing tools like cpu_list_lots and cpu_list_my_lots. It also enumerates the fields returned, making its purpose 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?

States this inspects a single lot by id, implying it's for when you have a specific lotId and need details. Doesn't explicitly name alternatives or exclusions, but the 'by id' wording vs list siblings provides clear context. 'Public read' also clarifies accessibility.

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 annotations, the description bears full responsibility for behavioral disclosure. It thoroughly covers read-only nature ('public, background-synced'), world structure (48,990 cells, no coordinates), caveats ('pos is only a rough hint'), return contents, and failure signal ('server.reachable false means actions will fail'). This is exceptionally transparent for a read tool.

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

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

The description is dense and front-loaded with the core purpose, then expands into necessary domain details. While it is a single long paragraph, it avoids redundancy and every clause adds value about the world, returns, or scopes. Minor structure improvements (bullets) would earn a 5.

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 no output schema, the description explains the return structure (summary, resourceIndex, storage) and their semantics, provides navigation guidance, and warns about `server.reachable`. Combined with the schema's full parameter coverage, this gives agents a complete and actionable picture for a complex 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 input schema already documents all four parameters with clear descriptions (scope enum, radius bounds, tokenIds requirement, aroundTokenId role). The description's scope list mostly restates schema info without adding new parameter-level meaning or clarifying dependencies beyond what the schema already states.

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 clear verb and resource: 'Read the live game world.' It distinguishes this tool from siblings by detailing the world model (finite sphere, tokenId keys, navigation via neighbors) and the available scopes, making it unambiguous that this is the broad world-reader 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?

The description provides context for when to use the tool ('Read the live game world') and implicitly contrasts with navigation via `cpu_next_hops` and action-related to-dos via `cpu_get_attention`. However, it does not explicitly state when not to use it or name alternatives like `cpu_get_cell`, so some inference is required.

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?

No annotations are provided, so the description carries the full burden. It discloses 'Public read' (indicating a non-mutating operation), and explains that liveSaleFeePercent is 'enriched from the local world map — advisory, may trail the chain' and is 'null when the rate is unknown'. These are valuable behavioral caveats about data freshness and null semantics, though it does not mention pagination, rate limits, or error behavior.

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 sentences and front-loaded with 'Scout the marketplace'. It efficiently covers the output structure, usage guidance, and important behavioral caveats in under 80 words. Each phrase adds value, though the density of details makes it slightly more information-rich than a simple two-sentence description would 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?

Given there is no output schema, the description thoroughly explains the return structure (one row per Hub/resource with counts, lowest price, distance, and fee) and the null/unknown fee behavior. It also covers all four parameters and provides usage recommendations, despite not mentioning ordering, pagination, or response size limits. This is complete enough for a read-only marketplace overview 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 input schema has 100% coverage with descriptions for all four parameters, so the baseline is 3. The description adds only a light relational grouping by calling aroundTokenId and radius an 'optional zone', but it does not deepen understanding beyond what the schema already provides. This is adequate but not exceptional.

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 states it 'Scout[s] the marketplace' and specifies the exact output: one compact row per (Hub, resource) with open-vs-incoming lot counts, lowest price, distance, and live sale-fee percent. It also distinguishes itself from the sibling tool cpu_list_lots by positioning this as the first look and that as the drill-down, so there is no ambiguity about what this tool does.

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 explicitly says it is 'The recommended first look at what is for sale and where' and advises to 'then drill into specific lots with cpu_list_lots'. This provides clear when-to-use context and names an alternative, satisfying the 5-level requirement for explicit 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?

With no annotations, the description carries full burden and excels: it discloses that mining matures in whole cycles (banking nothing mid-cycle), that stalls begin before the box reads full, that a stall burns time (schedule survives, wait does not), and that timestamps use the same clock as serverTime. This goes well beyond what annotations could provide.

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?

Although lengthy, every clause adds necessary behavioral nuance (stall mechanics, offload options, isFinished meaning, public access, timestamp reference). It opens with the core purpose and flows logically through return fields, edge cases, and related actions — no wasted words.

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

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

Given the complexity of mining state and the absence of an output schema, the description is remarkably complete. It covers return values, timing semantics, stall conditions, what happens when finished, public accessibility, and indicates the companion claim tool — enough for an agent to invoke and interpret results 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?

The single parameter tokenId is fully described in the schema (100% coverage, min/max, and a clear explanation). The description adds no additional parameter semantics, leaving the schema to carry the burden. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with 'Read a cell's mining job' — a specific verb and resource — and enumerates exactly what data is returned (active extractor, resource, yield, cycle length, progress, claimable units, timing, deposit, stall status). It clearly distinguishes from sibling tools like cpu_start_mining and cpu_claim_mining by focusing on read-only status inspection.

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 provides strong context: it states the tool is public (no session required), explains when results indicate the job is finished ('isFinished' means nothing more will be produced, claim it), and points to cpu_claim_mining for the owner to bank cycles. It also mentions offload options to resume from a stall, giving practical guidance on when to use this status read versus acting on it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly says 'Reads the deliveries projection,' signaling a read-only operation with no side effects. It also discloses the returned status fields (delivered, ready to finalize). It does not mention not-found behavior or auth requirements, but for a simple read this is sufficient.

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, compact sentence that front-loads the action ('Get one delivery...') and lists all relevant output details without any redundant or extraneous words. Every sentence 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?

For a one-parameter read tool with no output schema, the description covers the input (deliveryId), the nature of the operation (reads a projection), and the exact returned data points (source/target cells, resource, amount, arrival time, delivered status, finalize readiness). This is complete for an agent to select and invoke 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?

The only parameter `deliveryId` is already well-documented in the schema, including where to obtain it ('from `transport` or `list_my_transports`'). The description merely restates 'on-chain deliveryId' and adds no new semantic value. Schema coverage is 100%, so the baseline of 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?

The description clearly states the tool's function: 'Get one delivery by its on-chain deliveryId' with a specific verb and resource. It enumerates the exact fields returned, distinguishing it from sibling tools like `list_my_transports` (which lists multiple) and mutating actions like `cpu_finalize_delivery`.

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

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

The description implies usage when you already have a delivery ID and need its status, but it does not explicitly state when to prefer this tool over alternatives or mention exclusions. The schema adds context (ID comes from `transport` or `list_my_transports`), but that is outside the description itself. There is no explicit when-to-use/when-not-to-use guidance.

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

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

No annotations are provided, but the description states 'Public read,' confirming no side effects. It also notes that the server clamps radius to 50 and indicates defaults. This is sufficient transparency for a read-only browse tool.

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

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

The description is a single sentence that packs in many details efficiently. It uses punctuation effectively to separate ideas. Slightly more structured formatting (e.g., bullet points) could improve readability, but it is still concise and 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?

For a browse tool with 11 parameters and no output schema, the description covers filters, sort, pagination, availability, and zone constraints. It also references a related tool for further context. Missing details like exact return format are compensated by the schema richness.

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 baseline is 3. The description adds value beyond schema by explaining 'nearest needs a zone' and 'limit ≤ 200', and clarifying availability values. This helps the agent use parameters correctly.

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 states it's for browsing marketplace lots with filters, and distinguishes from sibling tools such as cpu_get_markets (compact overview) and cpu_list_my_lots (own lots). The verb 'browse' and target 'marketplace lots' is specific and 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?

The description provides a clear workflow hint: 'start with cpu_get_markets for a compact overview, then drill in here.' It also explains the availability default and alternatives (open, incoming, all). However, it does not explicitly list when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden. It mentions authentication ('Requires a session') and the scope of results ('across all lifecycle states'). However, it does not disclose whether results are paginated, sorted, or limited, nor any side effects. For a list operation, this is adequate but not comprehensive.

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

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

Two sentences with no redundant words. Front-loaded with the core action, followed by optional filter and use case. Every sentence contributes to understanding.

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 list tool with one optional parameter and no output schema, the description is mostly complete. It covers purpose, prerequisite, and use case. However, it omits the structure of the returned data (e.g., each lot object fields), which could be useful but is not critical given the simplicity.

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 input schema provides full description for the single parameter 'state' (enum values and default). The tool description adds usage context ('track create / cancel progress') but doesn't enhance parameter semantics beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'List the lots you have created'. It specifies scope ('across all lifecycle states') and optional filtering by state. This distinguishes it from sibling tools like cpu_list_lots, which likely lists all lots, not just user's.

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 provides a use case: 'Use this to find your lotIds and track create / cancel progress.' It also notes a prerequisite ('Requires a session'). While it doesn't explicitly mention alternatives, the context of sibling tools implies it's for personal lots. Slight gap in excluding when not to use.

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 annotations provided, the description carries the burden. It discloses behavioral traits beyond the name: it lists only 'the ones you paid for' (ownership scope) and specifies output fields ('source/target, amount, arrival time, and whether it is delivered or ready to finalize'). It does not mention pagination/ordering, but for a simple list tool it is reasonably transparent.

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

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

Three tightly-written sentences, front-loaded with the main action. The first sentence states the purpose and filter options, the second describes the output, the third gives usage guidance. No fluff or redundancy.

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

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

For a simple tool with one optional parameter, no annotations, and no output schema, this description is complete. It covers what the tool lists, the filtering options, the output content, and the primary use case (completing deliveries via cpu_finalize_delivery). No critical context is missing.

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

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

Schema coverage is 100% and the filter parameter already has a description and enum in the schema. The description adds meaning by explaining the filter values in context ('in_transit', 'delivered', 'ready_to_finalize') and the purpose of the filter, reinforcing the parameter's role in the delivery lifecycle beyond the schema's bare enum.

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 states the action: 'List your deliveries (the ones you paid for)' with specific verb and resource. It distinguishes from siblings like cpu_transport (which likely creates transports) and cpu_get_transport_status (which likely gets a single transport status) by explicitly scoping to the user's paid deliveries and including filtering options.

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 explicit usage context: 'Use it to find deliveries to complete with `cpu_finalize_delivery`.' This tells the agent when to use the tool and names the follow-up sibling. However, it does not explicitly contrast with alternative listing/status tools like cpu_get_transport_status, so it lacks 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?

With no annotations, the description carries the burden of disclosure. It clearly states the operation is public and lists the returned data fields, implying a read-only action. However, it does not explicitly state 'read-only' or mention any absence of side effects, though a 'list' operation strongly suggests no mutation.

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

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

Two sentences, no filler. The first sentence states the core functionality with specific detail; the second provides actionable usage context. Information is front-loaded and every sentence 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?

For a parameterless read-only list tool with no output schema, the description sufficiently explains the payload (recipe details) and usage timing. It also clarifies access requirements. Nothing critical 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?

The tool has zero parameters, so the baseline is 4 per guidelines. The description adds meaningful context about what the operation returns (recipes with inputs, outputs, duration, cost), which enriches the user's understanding beyond the empty 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 uses the specific verb 'List' and identifies the resource 'craft recipes,' detailing exactly what information is provided (inputs, outputs, duration, cost). It also distinguishes itself from sibling tools by pointing to cpu_craft as the next step.

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

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

Explicitly states when to use the tool ('before cpu_craft') and names the alternative/succeeding tool. The note 'Public — no session needed' also clarifies access requirements, providing clear context for use.

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 annotations, the description carries the full burden. It discloses key behaviors: payment in native ETH (not $CPU), minting to connected wallet, on-chain submission with confirmation wait, and need for sufficient balance. It doesn't describe the return value after confirmation, which is a minor 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?

The description is concise and well-structured, with each sentence serving a purpose: purpose, cost preview, payment method, balance check, and secondary market alternative. No redundancy.

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

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

Given no output schema and no annotations, the description covers usage, prerequisites, and alternatives thoroughly. It misses the return value after the on-chain wait, which would be useful, but overall it is quite complete for a single-parameter mint 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 has 100% coverage for the single 'quantity' parameter, so baseline is 3. The description adds meaning by relating quantity to the mint price and balance check, giving context beyond the schema's basic definition.

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 states the tool's function: 'Mint new land cells on the primary market, straight from the collection’s OpenSea SeaDrop public drop'. It uses a specific verb 'mint' and resource 'land cells', and distinguishes itself from related tools like cpu_quote_mint and secondary market operations.

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 provides explicit when-to-use and alternatives: preview cost with cpu_quote_mint, check ETH balance with cpu_get_balance, and for secondary market use OpenSea listings. It also states prerequisites like having enough ETH for price × quantity plus gas.

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?

No annotations are provided, so the description carries full burden. It fully discloses read-only nature, the subtle 'fromReady' build-state quirk, hub construction implications (no reach/fee until finished), foreign cells as walls, and the meaning of empty hops. This goes far beyond basic safety to explain genuinely non-obvious behavioral semantics.

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

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

Dense but well-structured: purpose first, then mechanics, then planning responsibility, then when-to-use. Every sentence adds value, though the length (5+ sentences) prevents a perfect score. The 'WHEN' marker helps skimmability.

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 complex tool with no output schema and no annotations, the description fully compensates: explains the reach rule formula, candidate facts, walls, hub building, fee behavior, and workflow integration. It covers edge cases (foreign cells, unfinished hubs) and gives actionable planning guidance.

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?

While schema coverage is 100%, the description adds critical meaning beyond field names: it explains that 'towards' is 'a compass, not a route,' clarifies that 'resourceId' determines the exact per-unit transit fee shown, and explains how 'from' being a hub or self-owned affects reach. This transforms dry schema definitions into actionable semantics.

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+resource: "Survey the legal next waypoints from a cell (read-only)." It clearly distinguishes this from siblings like cpu_quote_transport (which quotes transport cost) and cpu_route_network (which plans routes), while precisely defining the one-hop reach rule. This is a textbook example of a purpose that differentiates from alternatives.

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

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

Explicitly states when to use: "the cheap point check — call it right before each leg and after cpu_get_changes shows movement," and when to escalate: "replan via cpu_route_network only when a local fix is impossible." This is excellent guidance that maps directly to workflow context.

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

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

Fully describes read-only nature, no transaction, session requirement. Discloses transit fee re-quoting with ~10% headroom as ceiling, not extra charge. No annotations, so description bears full burden and does so excellently.

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?

Well-structured with front-loaded purpose. Contains valuable details but is slightly lengthy; still every sentence adds value.

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 behavior, parameters, return values, and comparison to sibling. Completing the lack of output schema by describing returns. For a complex preview tool, it is fully adequate.

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?

All parameters have schema descriptions (100% coverage). Description adds meaning by explaining chain as waypoints for transit fees, and returns (sale, transitFee, total) beyond 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?

Clearly states it's a read-only preview for buying from a lot, reserves nothing, sends no tx. Distinguishes from sibling cpu_buy_lot by advising use before it.

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

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

Explains two usage modes: with chain for exact total, without for seller-only estimate. Explicitly says 'use before cpu_buy_lot', providing clear when-to-use and alternative.

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 annotations, the description carries the full burden and explicitly discloses 'It has no side effects — no transaction' and that it 'reads the live public drop.' This is transparent about the read-only nature. It could additionally describe edge cases (e.g., if drop is inactive), but the core behavior is well 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?

Exactly two sentences, front-loaded with purpose, and every phrase adds value. No filler words or redundant information; the description is tightly written and well-organized.

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?

The tool is simple (one optional parameter, no output schema). The description explicitly lists the return values (per-cell ETH price, total, drop window, per-wallet limit) and the use case (pre-mint sizing), making it complete for this request/response model. No annotations are needed because the description covers the safety profile.

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 references `quantity` in context ('total for `quantity` cells') but adds no new meaning beyond what the schema's description already provides. It reinforces the usage without expanding semantics.

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 states this tool previews a primary-market land mint without committing. It specifies the action (reads live OpenSea SeaDrop drop) and the exact outputs (per-cell ETH price, total, drop window, per-wallet limit), and distinguishes itself from cpu_mint_cell by naming it.

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

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

Explicitly states 'Use it before cpu_mint_cell to size the buy and confirm the drop is active.' This gives direct guidance on when to use and identifies the alternative execution tool, effectively covering the 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?

With no annotations, the description fully discloses behavior: no side effects, no transaction, output is net of pool fee, and slippage is applied. This goes beyond a basic description and gives the agent critical safety information for a quote-only tool.

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

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

Three tightly written sentences. Front-loaded with the core action and non-committal nature, then necessary details and usage pointer. No redundant words or repetition of schema fields.

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 no output schema, the description explains exactly what is returned (expected output and minimum after slippage) and the context (pre-swap sizing). The tool is a simple quote with 3 well-documented parameters, so the description is sufficient for an agent to select and 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 covers all parameters with descriptions, so baseline is 3. The description adds value by explaining the output is net of pool fee and that slippage determines the minimum received, connecting the parameter to its behavioral effect beyond just its type/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 'Preview' and clarifies it's an ETH↔$CPU swap without committing, immediately distinguishing it from the actual `cpu_swap` tool. It clearly states the tool's function: returns expected output and minimum after slippage.

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 instructs to use it before `cpu_swap` to size the trade. It also states what the tool does NOT do ('no approval, no transaction'), which sets clear expectations and guides the agent away from using it for execution.

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?

No annotations, but description fully covers: read-only, no side effects, validation, surfacing rejection reasons. Discloses return values.

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

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

Four sentences, front-loaded with purpose, each sentence provides value. No fluff.

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 3-param tool with no output schema, description covers return values, validation behavior, and integration with sibling tools. Complete for its 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 coverage is 100% and descriptions in schema are detailed. Description adds no new info beyond referencing `cpu_next_hops`. Baseline 3 per rules.

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?

Description clearly states the tool previews a transport route without committing, returns fee/distance/timestamp, and distinguishes from `cpu_transport` (commits) and `cpu_next_hops` (scouts). Specific verb and resource.

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

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

Explicitly says 'use this before cpu_transport' and 'Scout waypoints with cpu_next_hops', providing clear when-to-use guidance and alternatives.

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?

No annotations provided, so description carries full burden. Discloses on-chain transaction, ETH fee requirement, free first reveal vs re-reveal conditions, asynchronous deposit behavior. Lacks details on failure modes or exact consequences of conditions not met.

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?

Description is brief and well-structured, with main purpose first, then prerequisites, then fee and async details. Every sentence adds value, no fluff.

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 essential workflow: authenticate, reveal (with ETH fee), async deposit, and reading with cpu_get_cell. Missing details on tool's return value and edge cases like insufficient ETH or re-reveal conditions, but still adequate for a simple 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 has 100% coverage with clear parameter description. Overall description does not add new information about the parameter beyond what schema already provides, so 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?

Description clearly states it reveals deposits of a cell you own. The verb 'reveal' and resource 'deposits of a cell' are specific. It distinguishes from siblings like cpu_get_cell (which reads after reveal) and cpu_authenticate (prerequisite).

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 clear context: must call cpu_authenticate first, mentions asynchronous deposits and alternative tool cpu_get_cell for reading results. However, does not explicitly state when to use or avoid using this tool relative to alternatives.

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 annotations, the description carries the full burden and does so exceptionally well. It discloses read-only nature, node/edge construction rules, hub states, foreign cell walls, component id meaning, bridging strategies, and the closed sphere. It goes far beyond typical descriptions in explaining edge cases and strategic implications.

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

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

The description is long but dense with relevant information. It is front-loaded with 'road map of the world (read-only)' and follows a logical structure. Some sentences could be tightened, but the verbosity is justified given the tool's complexity.

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 no output schema, the description enumerates node fields (owner, hub flag, ready state, fee, pos, component id) and edge rules. It covers hub construction states, foreign cell behavior, component meaning, and strategic use cases. This is more than sufficient for an agent to correctly invoke the tool and interpret results.

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

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

Schema coverage is 100%, so baseline is 3. The description adds valuable context: from/towards are for annotating distances 'to reason over', and resourceId determines the fee shown. Although the schema already describes the parameters, the description ties them to the map's purpose and strategy, slightly exceeding baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('road map of the world') and clearly identifies the resource (graph nodes/edges for movement). It distinguishes itself from siblings by explicitly saying 'Routing over this map is YOUR job' and comparing with cpu_next_hops and cpu_quote_transport.

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

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

Explicit usage guidance is provided: 'WHEN: the heavy read — plan a journey or a big replan; for point checks while executing use the cheap cpu_next_hops.' It also tells the agent to verify via cpu_quote_transport, giving clear when-to-use and alternatives.

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?

No annotations provided, so the description must fully detail behavior. It explains that rates only apply to new listings, not open lots, and can be set on a hub under construction. Also mentions revert conditions and return value.

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?

Description is informative but slightly verbose (5 sentences). Key information is front-loaded, but could be more concise. However, it contains no wasted words and is well-structured.

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

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

Given the tool has 3 required parameters, no output schema, and no annotations, the description covers all necessary context: prerequisites, parameter semantics, behavioral nuances, return value, and error conditions. Fully sufficient for correct usage.

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 descriptions for all parameters. Description adds minor context ('loop for several' for resourceId) but largely aligns with schema. Baseline score of 3 is appropriate given high schema coverage.

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 states the action: setting a sale-fee rate on a Hub you own. It specifies the resource and lists the range (0-50, 0.01 granularity), distinguishing it from any sibling 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?

Explicitly states prerequisites: requires a session via cpu_authenticate. Provides guidance on looping for multiple resources, setting 0 for free, and reverts conditions. Clear when to use and what to avoid.

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 annotations provided, the description fully discloses important traits: costs no CPU, job is non-cancellable, holds process slot, cannot demolish mid-job, does not overrun, and effects on other operations. This is thorough and beyond the minimal.

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 detailed but well-organized, starting with the action and prerequisites, then explaining behavior. It could be slightly more concise, but every sentence adds value. No redundancy.

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

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

The description covers all aspects: prerequisites, side effects (cell slot lock), scheduling advice, and references to related tools (cpu_get_mining_status, cpu_claim_mining). No output schema, but the return value is implied through tracking tools. Complete for a complex operation.

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 input schema has 100% coverage with detailed descriptions. The tool description adds context (e.g., 'batches is a commitment you cannot undo', 'omit targetResourceId when extractor mines a single resource'), enhancing understanding beyond the schema alone.

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 states the action: 'Start a bounded extraction job on a cell you own that holds a finished extractor.' It uses specific verbs and resources, and distinguishes from siblings like cpu_claim_mining and cpu_get_mining_status.

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

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

The description explicitly mentions prerequisites: session via cpu_authenticate, cell ownership, finished extractor, and building construction. It also gives guidance on when to omit targetResourceId and advises checking cpu_get_game_config and cpu_get_cell beforehand. It does not explicitly list when not to use it, but provides sufficient context for decision-making.

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 annotations provided, the description fully carries the behavioral burden. It discloses exact-input semantics, slippage application as a floor, Permit2 auto-approval for CPU, on-chain submission and confirmation waiting, and the 1% pool fee. This is comprehensive and gives the agent a clear 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?

The description is dense but every sentence earns its place. It front-loads the core purpose and direction, then logically explains amount, workflow, slippage, approval, and fee. It could be slightly shorter, but the structure is clear and no information is redundant with the structured schema.

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

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

Given there is no output schema, the description covers all the important aspects of the swap: direction, amount, slippage, fee, and on-chain behavior. The only gap is that it does not describe the expected return value (e.g., transaction hash or receipt), which would help the agent know what to do with the result. Still, it is complete enough for safe 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?

Schema coverage is 100% (all three parameters have descriptions). The description reinforces the schema's meaning (e.g., `sell` directions, `amount` as spend amount, `slippage` as a percent) but adds little beyond what the schema already states. The Permit2 approval detail is behavioral, not parameter-specific, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Swap between native ETH and $CPU'), the resource ('game token pool (Uniswap v4)'), and supports both directions with explicit `sell` enum mapping. It also distinguishes itself from the sibling `cpu_quote_swap` by labeling that as a preview and this as the execution.

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 provides clear usage context: it tells the agent to preview with `cpu_quote_swap` first, implies this tool is for executing the actual swap after quoting, and explains the slippage and exact-input behavior. It does not explicitly mention alternatives or when not to use, but for a swap tool the guidance is sufficient.

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 annotations, the description fully discloses behavior: on-chain execution, atomic debit, transit fee payment (auto-approved once), escrow with time-delayed delivery, hop radius constraints, and that goods credit only after calling cpu_finalize_delivery. It also mentions return values and fee waiver conditions. This is comprehensive.

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 dense but well structured, front-loading the core action then layering prerequisites, constraints, and flow. It is longer than average but every clause adds useful information; could be slightly trimmed for conciseness but remains efficient.

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 complex tool with no output schema, the description covers prerequisites, authentication, constraints, recommended flow, return values, post-conditions, and edge cases (e.g., own-cells fee waiver). It gives the agent everything needed to invoke this 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 description coverage is 100%, so baseline is 3. The description repeats path constraints already in the schema and adds minimal new parameter-specific meaning; the additional context (fees, atomicity) is more about general behavior than the parameters themselves. It does not significantly enhance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Move a resource between cells along a waypoint chain of tokenIds', giving a specific verb, resource, and method. It clearly distinguishes from siblings like cpu_next_hops, cpu_quote_transport, and cpu_finalize_delivery by placing transport as the action that executes the move.

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 explicit recommended flow: scout with cpu_next_hops, chain waypoints, verify with cpu_quote_transport, then execute. Also states when not to pay fees (own cells only) and prerequisites (session via cpu_authenticate). This offers clear when-to-use and alternative tooling 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?

With no annotations, the description fully discloses behavior: debits the cell, mints $CPU, waits for confirmation, returns tx hash. It also mentions no approve needed and warns that wCPU is tied to the cell.

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 paragraph that front-loads the main action. It contains necessary detail but could be slightly more concise. However, it is well-structured and informative.

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?

Without an output schema, the description covers return value (tx hash) and suggests checking with cpu_get_balance. It includes prerequisites, constraints, and consequences, making it fully complete for a 2-param 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 100% and already describes parameters. Description adds value by providing examples (e.g., '100'), clarifying units ('whole wCPU units'), and referencing get_cell to check balance.

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 states the action: 'Cash out a cell’s wCPU to the on-chain $CPU token'. It includes the resource ID, conversion rate, and prerequisites. Differentiates from siblings by being the only tool for converting wCPU to $CPU.

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 specifies when to use (to convert wCPU to $CPU) and prerequisites: need a session via cpu_authenticate and own the cell. It warns about selling the cell. Does not explicitly state when not to use, but context is clear.

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