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

With zero annotations, the description carries the full behavioral burden, and it delivers: atomic multi-step execution (prepares, re-checks exact offer/Cell, sends owed collection approval, waits for receipt), failure modes (staleOffer/unfulfillable sell NOTHING), proven-success criteria (protocol fulfilment event, sender wallet, ownership transfer), post-sale active criteria offers, and detailed retry semantics. This exceeds what any annotation set would typically 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?

The description is front-loaded with the core purpose and logically organized (purpose → market distinction → usage → execution → failure → retry → result). It is long, but for a high-stakes mutation tool with no annotations the detail is mostly earned. Some redundancy, such as the no-substitution guarantee and retry safety being restated, keeps it from a perfect score.

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 marketplace mutation with zero annotations, the description is remarkably complete: prerequisites, parameter requirements per offer type, failure modes, approval handling, retry safety, and result semantics (status, orderHash, Cell, buyer, pre-fee amount/currency, txHashes in order) are all covered. The existence of an output schema is a bonus since return values are already explained in prose.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value on top: it explains why tokenId is REQUIRED for criteria offers and the exact consequence of omitting it (call fails before sending anything), ties orderHash to its sourcing tool, and clarifies the no-substitution guarantee. This pushes it 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 opens with a precise verb+resource statement: "Sell ONE Cell you own by accepting ONE exact offer on the NFT marketplace, in a single call." It explicitly distinguishes itself from cpu_create_lot (sells RESOURCES, not Cells) and from sibling offer-making/buying tools, so an agent can tell it apart without inspecting schemas.

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

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

The description gives explicit when-to-use guidance: read cpu_get_my_offers_received first, copy the exact orderHash, and pass tokenId only for trait/collection offers. It also names the alternative (cpu_create_lot) and the condition that selects it, plus failure conditions that terminate the call safely.

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 mode-specific side effects (SIWE local sign-in and token storage, browser authorization with URL fallback), session caching behavior, and the downstream consequence that wallet-dependent tools start working automatically. This is strong behavioral disclosure.

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 and trigger conditions, then moves into modes and parameter behavior. It is mostly tight, but the final sentence about calling cpu_persona before replying is a workflow directive rather than tool behavior, slightly diluting focus.

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

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

For an authentication tool with no output schema, the description covers the failure trigger, two authentication modes, force semantics, and downstream effects. It does not explicitly describe the success return shape in EVM mode, but that is a minor gap given the context and the tool's purpose.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the force=true use case with a concrete stale-session example and by describing the Paybox-mode context, which makes the parameter semantics more actionable.

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: 'Create a blockchain session.' It then clarifies the tool's role as the authentication/session entry point among many wallet-dependent siblings, so an agent can distinguish it from tools like cpu_get_balance or cpu_build without opening schemas.

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

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

The description explicitly states when to use this tool: 'Call this tool when other tools fail with authentication or session errors.' It also gives precise conditional guidance for force=true and for EVM vs Paybox modes, leaving little to inference.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the $CPU cost and auto-approval, on-chain placement and confirmation wait, construction delay, one-building-per-cell limit, safe no-op on rebuild, and the post-demolition cooldown lock. This is unusually 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?

The description is dense but every sentence contributes a distinct fact: precondition, catalog, cost/side effect, timing, follow-up actions, idempotency, demolition path, and result inspection. It front-loads the core purpose and keeps the practical constraints tight.

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 mutating, on-chain tool with no output schema, this description covers prerequisites, cost, timing, idempotency, capacity constraints, cooldowns, next steps, and how to verify the result via cpu_get_cell. No critical operational gap remains.

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 adds semantic value by explaining that an extractor mines, a crafter runs recipes, the hub routes transport/trade, and that tokenId must reference a revealed cell you own. It enhances, rather than merely repeats, the schema.

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

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

The description opens with a specific verb and resource: 'Place a building on a revealed Land cell you own.' It clearly distinguishes this from sibling tools like cpu_demolish, cpu_get_building, cpu_start_mining, and cpu_craft by explaining what build does and what happens next.

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

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

It explicitly states the prerequisite (cpu_authenticate first), where to find valid options (cpu_get_game_config), what to do after the building finishes (cpu_start_mining or cpu_craft), how to switch buildings (cpu_demolish first), and the cooldown caveat. This is strong routing guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers thoroughly. It reveals the call's internal workflow: preparing the purchase, verifying the exact order, sending owed currency approval, waiting for the receipt, and sending the fulfilment transaction. It also discloses retry safety ('can never bind a second order'), proof requirements, and the exact failure modes, which is exceptional transparency for a financial 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?

The description is long, but the length is justified by the tool's financial risk and complexity. It is front-loaded with the core action, then covers prerequisites, failure modes, safety, and result semantics. There is some redundancy around 'exact order' and 'never substitutes a different listing', which appears multiple times, so it is not perfectly concise.

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 high stakes—spending currency, sending approvals, and fulfilling an NFT order—the description is remarkably complete. It covers prerequisites, failure conditions, retry behavior, proof of success, what the result reports, and even the worst-case retry cost. The input schema and output schema provide the remaining structured detail, so 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?

Although the schema already covers all parameters at 100%, the description adds valuable behavioral meaning beyond the schema. It explains that expectedOrderHash must be copied from cpu_get_cell_market and binds the purchase to that exact listing, clarifies maxAmount is a hard ceiling in base units and must be a decimal integer string, and ties tokenId to the specific Cell the listing sells. This is more than the schema alone provides.

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

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

The description opens with a specific verb and resource: 'Buy ONE exact Cell listing on the NFT marketplace, in a single call.' It explicitly contrasts this with cpu_buy_lot, which buys resources for $CPU, so the agent cannot confuse the two. The scope ('ONE exact Cell listing', never substitutes another listing) is unusually precise.

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

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

The description gives an explicit prerequisite: read cpu_get_cell_market first and pass that listing's exact expectedOrderHash. It also names the key alternative, cpu_buy_lot, and states the exact condition that separates them (land/NFT market vs in-game resource purchases). It further clarifies what happens if the order is stale, cancelled, expired, or repriced, so the agent knows when the call will fail.

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 behavioral burden. It discloses the atomic single-transaction cost composition, the ~10% headroom ceiling on transit-fee approval, the on-chain revert behavior for frozen lots, first-buy auto-approval, allowance of buying your own lot, and the lot-state re-read guard before any token approval or transaction.

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 information-dense and front-loaded with the core action. Each sentence contributes a distinct operational fact (cost composition, approvals, freeze behavior, finalization, precondition guard, result fields) with no 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?

For a complex on-chain mutation with no annotations and no output schema, the description covers prerequisites, cost breakdown, fee drift headroom, failure modes, the required follow-up cpu_finalize_delivery call, and the meaning of result fields like paid, tax, and ownerNet. An agent has sufficient context to invoke the tool correctly and interpret the outcome.

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 three parameters completely (100% coverage), so the baseline applies. The description adds some useful context, such as the cost formula value × pricePerUnit and chain construction, but most parameter meaning already lives in the schema, so the added value is modest rather than substantial.

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

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

The description states a specific action (Buy units), a precise resource (an OPEN lot), and the delivery target (your own cell), which separates it from quoting, transporting, creating, or finalizing operations. It also names related siblings like cpu_quote_buy, cpu_finalize_delivery, and cpu_get_lot within the text, so the agent can orient immediately.

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 tells the agent to preview the exact cost with cpu_quote_buy, to finalize delivery with cpu_finalize_delivery using the returned deliveryId, and to detect frozen lots up front with cpu_get_lot. It also states the session prerequisite and explains that non-open lot states abort the call before any token approval or transaction, so an agent knows when this tool is not appropriate.

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 full burden, and it discloses a great deal: single transaction, contract-pin check, byte-level cancellation verification, receipt and event-based proof, stale-order failures, safe retry semantics, and worst-case gas cost. This is exceptional transparency for a state-changing tool, especially around idempotency and failure modes.

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 appropriately front-loaded with the core purpose, and nearly every sentence contributes operational or safety-critical information. A few rhetorical rewordings, such as 'Success is proven, not assumed' and 'YOU PICK THE ORDER,' add emphasis rather than new facts, and some result details overlap with the output schema. Still, the density is justified for a destructive-looking action with retry and proof semantics.

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 high-stakes cancellation tool with one parameter and no annotations, the description is remarkably complete: prerequisites, ownership restriction, transaction flow, proof criteria, stale-order behavior, retry safety, and result fields are all covered. An agent has enough context to know whether it should call this tool and what to expect before, during, and after 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%, and the schema already describes orderHash as the exact 32-byte 0x-prefixed hash of your own Market order. The description adds context beyond the schema by instructing where to source the hash (cpu_get_my_listings or cpu_get_my_offers), emphasizing it must be YOUR OWN order, and clarifying the side is inherent to the order rather than a selectable parameter. This is meaningful added guidance, though partly reinforcing the schema.

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

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

The description opens with a specific verb, resource, and scope: cancel exactly one Market order on the NFT marketplace in a single call. It clearly distinguishes this from cpu_return_lot, which ends a resource Lot, and explains the same input cancels both listings and offers. An agent can confidently identify what this tool does and how it differs from its siblings.

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 tells the agent to read cpu_get_my_listings or cpu_get_my_offers first and pass the exact orderHash, names cpu_return_lot as the alternative for a different resource type, and states the wallet-ownership requirement. It also gives clear failure expectations, such as staleListing/staleOffer, so an agent knows when the call is appropriate and what happens otherwise.

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 full behavioral burden. It discloses the core side effect (banking matured batches), the no-op/error conditions, and the slot-freeing consequence. It does not mention the return value or response shape, which keeps it from a 5.

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

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

The description is four concise sentences, each earning its place: purpose, prerequisite, edge-case behavior, and slot-freeing consequence. The main action is front-loaded and there is no filler or repetition of schema details.

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 mutation tool with no annotations and no output schema, this description covers purpose, prerequisites, edge cases, and the recommended preceding status check. The only notable gap is the absence of any statement about what the response contains or looks like.

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

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

Schema description coverage is 100% and already explains tokenId as 'the tokenId of the cell whose craft processes to act on.' The description adds ownership context ('a cell you own') but does not materially expand parameter semantics beyond the schema, 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?

The opening sentence names a precise verb ('Bank') and resource ('matured craft batch on a cell you own into its resource balance'), and clearly distinguishes this from siblings like cpu_craft and cpu_get_craft_status. The action is unambiguous and specific.

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 requires a session and tells the agent to call cpu_authenticate first. It also states when the call is a no-op success versus an error, and tells the agent to check cpu_get_craft_status first for claimable batches. This is concrete, actionable usage 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 at all, the description carries the full burden and delivers extensively: it discloses no-op behavior, the no-extractor error case, partial-cycle settlement ('only whole cycles settle — if a full cycle of output does not fit, nothing banks and the wait resets'), the fact that claiming does not stop a running job, and retirement freeing the process slot. This is far 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?

Six dense sentences, each earning its place by disclosing a distinct behavioral rule or prerequisite. The core purpose is front-loaded, followed by edge cases in logical order. Slightly long but justified given the absence of annotations and output schema; better structuring of prerequisites vs. edge cases would push it to 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?

Given the high behavioral complexity and no annotations or output schema, the description covers nearly everything an agent needs: authentication prerequisite, status pre-check, error conditions, partial-settlement semantics, side effects, and retirement behavior. The only gap is return-value semantics — how the agent learns how much was banked or that the no-op occurred.

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%: tokenId is documented as 'a cell you own with an extractor, to bank its matured mining cycles.' The description reinforces the ownership and extractor conditions but adds little semantic value beyond the schema, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource statement: 'Bank every matured mining cycle an extractor has produced on a cell you own into its resource balance.' This clearly distinguishes cpu_claim_mining from siblings like cpu_start_mining (initiating work) and cpu_get_mining_status (checking state), so an agent can tell them apart without inspecting schemas.

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

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

The description gives explicit prerequisites ('Requires a session — call cpu_authenticate first') and a pre-check flow ('Check what is available first with cpu_get_mining_status'), plus expected outcomes (no-op, error). It stops short of an explicit when-not-to-use statement naming an alternative tool for a different scenario, so it misses 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels: it explains upfront debit of inputs, free vs. paid recipes, the one-time unbounded CPU approval for forge_wcpu, delayed timer start after indexer settlement, switch-cost burning, and free cases for first pick/restart. It also discloses that the result reports recipe cost and switch cost separately.

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: core action first, then prerequisites, then payment/cost behavior, then switch-cost nuance, then pre-commit guidance and post-invocation tracking. Every sentence adds essential operational detail for a complex on-chain crafting tool, and no redundant filler is present.

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 annotations and no output schema, the description is remarkably complete. It covers prerequisites, cost behavior, edge cases, what the result reports, and how to follow up. An agent has enough context to invoke cpu_craft correctly and interpret what happened afterward.

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?

Although the schema already covers 100% of parameter descriptions, the tool description adds meaningful semantics beyond the schema. It clarifies batches are debited upfront with no cancel behavior, explains forge_wcpu's special CPU cost and approval flow, and details when a Switch cost is or is not burned for recipeId changes.

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: "Run a craft recipe on a cell you own (refine raw resources, or forge $WCPU)." This clearly distinguishes the action from sibling tools like cpu_list_recipes, cpu_get_craft_status, and cpu_claim_craft, which handle discovery, status, and claiming respectively.

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 and lifecycle routing: call cpu_authenticate first, discover recipes with cpu_list_recipes, check prices via cpu_get_cell, track progress with cpu_get_craft_status, and bank results with cpu_claim_craft. It leaves no ambiguity about when this tool should be invoked versus related tools.

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 full burden and delivers richly: it discloses the atomic-transaction nature, the DELIVERING-to-OPEN state transition gated on escrow arrival, the freezing/revert behavior when the hub's live fee exceeds maxSaleFeePercent, transit-fee auto-approval, and the pre-transaction refusal safeguard. These are non-obvious behaviors an agent could not infer from the schema alone.

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 every sentence earns its place given the tool's complexity: atomic tx, layered fees, freezing logic, delivery state, and prerequisites. It is front-loaded with the core action and the session requirement before diving into mechanics. It is one dense paragraph and would benefit from light structural breaks, but there is no 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?

For a high-complexity tool with no annotations and no output schema, the description is remarkably complete: prerequisites, the refusal safeguard, the post-call delivery step, return values (lotId, locked-in maxSaleFeePercent), fee and freezing edge cases, and tracking tools are all covered. An agent has everything needed to invoke it correctly and to handle the states that follow.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine meaning: the chain parameter's cost model (foreign-hub transit fee, auto-approval once, free over own cells), the sale-fee carve-out meaning the buyer still pays exactly price × value, and how maxSaleFeePercent drives lot freezing. The maxSaleFeePercent prose partly duplicates the schema's own detailed description, which keeps this from a 5.

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 opening sentence states a specific action — 'List units of a resource for sale at a Hub, on-chain' — and the rest confirms it opens a lot in one atomic transaction. The creation role is unmistakable against sibling tools like cpu_buy_lot, cpu_return_lot, and cpu_evict_lot, even without naming them, because the description centers on opening a listing and shipping goods to the hub.

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 sequences the calling flow: authenticate first, read cpu_get_lot_terms before calling (the tool re-reads the same terms and refuses before any approval or transaction), then call cpu_finalize_delivery on the returned deliveryId, and track with cpu_list_my_lots / cpu_get_lot. The when-to-use context is concrete and the adjacent/alternative tools are named in 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?

No annotations are provided, so the description carries full burden. It discloses key behaviors: auto-join as first member, cooldown on leaving, default manager, on-chain write requirement, and detailed failure conditions (already in syndicate, empty/over-long name/link, rate >100%, registry not deployed). This is exemplary 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 a single dense paragraph that front-loads the primary action and then efficiently covers constraints, side effects, and failure modes. Every sentence contributes meaningful 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?

For a complex on-chain write with nested parameters and no output schema, the description comprehensively covers creation behavior, result contents (id, join time, earliest leave), cooldown implications, manager semantics, rate validation, and edge-case failures. Very thorough.

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 value by explaining the four rates collectively as 'same-syndicate trade/transport discounts and the trade/transport tax the manager collects', and clarifies that manager can be passed to another wallet. It also reinforces the basis-point precision constraint.

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 'Found your own syndicate' and clearly enumerates the parameters (name, link, four fee rates), distinguishing this creation tool from siblings like join_syndicate and leave_syndicate. The verb 'create' is implied by the function name and reinforced by the full context.

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 tool's purpose as the creation entry point is clear, and it explicitly warns that failing occurs if already in a syndicate ('leave first'), giving a when-not-to-use condition. It does not explicitly name alternatives, but sibling names like join_syndicate and set_syndicate_params provide 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 provided, the description carries the full disclosure burden and meets it thoroughly: costs CPU and consumes materials with no refund, preserves deposits and warehouse balances, locks the plot during a cooldown, and details mining/craft/hub edge cases. It even points to cpu_get_game_config for exact demolishCost figures.

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 core purpose is front-loaded in the first sentence, and each subsequent sentence earns its place covering costs, restrictions, preserved state, and cooldown. The length is fully justified by the number of behavioral constraints a caller must know before invoking a destructive operation.

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

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

For a destructive tool with no annotations and no output schema, the description covers every major concern: authentication prerequisite, exact cost sources, failure-condition edge cases, post-demolition cooldown, and where to verify it (cpu_get_cell/cpu_get_attention). The only omission is the return payload, which is minor for a side-effect-driven action.

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

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

Schema coverage is 100% for the single tokenId parameter, so the baseline is 3. The description adds genuine meaning beyond the schema by defining which tokenIds are valid targets — cells with no active mining/craft processes, hubs in a non-busy state — and by noting the rebuild cooldown that follows on the same cell.

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 first sentence states a specific action — 'Remove the building from a Land cell you own' — with a clear outcome ('clearing it for a different building'). This unambiguously distinguishes it from building-related siblings like cpu_build and cpu_upgrade.

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

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

The description gives strong when-to-use context ('clearing it for a different building') and a hard prerequisite ('call cpu_authenticate first'). It enumerates explicit exclusion conditions — no active mining or craft process, hub not mid-route or anchoring open trade lots — but never names or contrasts an alternative tool for comparison.

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 full transparency burden and does so admirably. It explicitly states what the tool does not do: moves no goods, seizes nothing, never finalizes a delivery, never touches more than the one named lot, and never brings anything home. It also clarifies the ownership and escrow implications for the buyer, seller, and Hub.

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 more expansive than typical tool docs, but every sentence earns its place by clarifying scope, exclusions, side effects, or alternatives. It is front-loaded with the action and requirements, though the long multi-clause explanation of Hub counting could have been tightened or structured with bullets.

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 are no annotations and no output schema, this description is complete for safe invocation. It fully explains the preconditions, the behavioral limits, the effect on Hub storage and demolition, and the only valid alternative path (cpu_return_lot for one's own lots). An agent has all the context needed to decide when and how to call the tool.

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

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

The input schema already provides 100% coverage of the single lotId parameter, including its source endpoints and required conditions (open, foreign, on a Hub you own, one lot per call). The description reinforces these constraints but does not significantly add new parameter-level meaning 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 names a precise action — evict one foreign OPEN lot off a Hub you own — and explains the narrow scope of what the tool does. It clearly differentiates itself from the sibling cpu_return_lot by stating that only the seller can return goods and that this tool never brings anything home.

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 when-to-use context: remove a foreign open lot from your Hub storage, stop it selling, and stop it counting toward Hub demolition. It also gives an explicit exclusion — your own lot cannot be evicted — and routes to cpu_return_lot as the alternative. The Hub demolition explanation provides valuable 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 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 provided, the description carries the full behavioral burden, and it does so comprehensively: read-only, no session needed, no-match returns a plain answer rather than an error, default limit behavior, and single-match card behavior. It also clarifies the lifecycle distinction between buildInput and recipeInput, which is critical for correct invocation.

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

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

The description is dense but well-structured: search intent first, parameter semantics second, output shape third, and edge cases last. Every sentence carries operational information, and there is no filler or redundant restating of the tool name.

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 and no annotations, this description covers invocation semantics, result format, default row count, filtering strategy, edge cases, and session/auth requirements. An agent has enough context to call it correctly across common scenarios.

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 seven parameters already have schema descriptions, so the baseline is 3. The description adds value by grouping the four resource filters into distinct roles and explaining the AND-combination semantics, going beyond the per-property schema text. It does not reinvent the parameter details, but it does synthesize them into actionable guidance.

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 search dimension: 'Search the building catalog by what a building consumes, produces or mines', plus an illustrative query. It clearly distinguishes this from the closest sibling, cpu_get_building, by mentioning the single-match full-card behavior. This is far more than a tautology.

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

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

It explicitly states filters are optional and AND-combined, that kind and tier narrow results, and advises narrowing filters rather than paging. It references cpu_get_building for the single-match case, implying the boundary, but it does not explicitly say 'use cpu_get_building for exact ID lookups' or 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?

With no annotations, the description carries the full disclosure burden and meets it: it mentions gas cost, no second reveal, default batch behavior, tokenIds scoping, requestId+source override, idempotent handling of settled requests, and refusal on auto-delivery networks.

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 each sentence contributes a distinct fact: core action, prerequisite, network-dependent behavior, batching, direct settlement fallback, and error semantics. It is front-loaded and contains no filler.

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

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

For a chain call with no annotations, no output schema, and conditional network behavior, this description covers prerequisites, all parameter modes, error behavior ('Requests already settled are reported as such, not as errors'), and unsupported-network exclusion. Nothing essential for correct invocation 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%, so the schema already documents all three parameters precisely. The description restates their usage in context (e.g., 'requestId plus source') but adds no new format, range, or constraint semantics, so the high-coverage baseline 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 ('Finish reveal requests you already opened...') and immediately distinguishes the tool from siblings by noting it 'sends the missing draw on-chain' and 'pays for no second reveal.' This is not a tautology and clearly differentiates it from related tools like cpu_reveal.

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

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

It gives explicit prerequisites ('call cpu_authenticate first'), points to cpu_get_game_config to determine the randomness mode, and states when not to use the tool ('On a network where the randomness source delivers draws itself this call refuses'). This is a clear when/why/alternatives policy.

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 and no output schema, the description carries the full burden and does so thoroughly. It discloses that items are descriptive only and suggest no action, that lot/reveal flags cover only your own wallet, that owner-scouting is read-only, that results are severity-filterable, and that partial lookup failures still return remaining items with a `note`. This is rich behavioral detail beyond the schema.

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

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

The description is long and dense, but almost every clause carries operational value, especially because there is no output schema to explain the returned flags. It is front-loaded with the core purpose and organized by severity, though the long flag enumeration is harder to parse than it could be.

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

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

For a complex roll-up tool with no output schema and no annotations, the description is unusually complete: it covers sort order, severity semantics, item fields, auth requirements, read-only scoping, partial failure behavior, and per-flag interpretation. An agent has enough context 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?

Schema coverage is 100% and both parameters are already well described there. The description restates `owner` and `minSeverity` briefly but adds no meaningful semantic information beyond the schema; therefore 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 identifies a clear verb and resource: a roll-up of cells worth attention, scoped to the owner and sorted by urgency. It distinguishes itself from map-scanning tools by explicitly saying it exists so you can skip scanning the whole map, and the flag taxonomy makes its purpose concrete.

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

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

It clearly tells the agent when to use this tool: to get an attention-ordered summary instead of scanning the map. It also gives usage context for authentication (authenticated wallet for own cells), for scouting another player via `owner`, and for filtering via `minSeverity`. It does not explicitly name sibling alternatives or state exclusions, but the context is strong enough.

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?

With no annotations, the description assumes full responsibility for behavioral disclosure. It explicitly declares 'Read-only' and 'No session needed', and it details the three plan modes plus the distinction between build inputs and recipe inputs, giving an unusually complete picture of what a call returns.

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

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

The description is front-loaded with the core purpose and then efficiently organized by labeled plan categories (CONSTRUCTION, OPERATION, LIFECYCLE). The dense detail is warranted because the tool has no output schema and the description must carry the return-value semantics.

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, no-output-schema tool, this is complete: it gives the prerequisite for obtaining the type, explains the three plan groups and their subcategories, clarifies cost timing, and states read-only and session requirements. There are no obvious gaps that would prevent correct invocation.

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

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

The schema already documents buildingType with 100% coverage, including an example ('steel_mill') and the get_game_config source. The description reinforces that the parameter is the catalog type but adds no new format, constraints, or examples 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 opening line 'One building of the catalog as a card' clearly identifies the resource and the operation: retrieve a single catalog entry. It also names the input source via cpu_get_game_config, which helps distinguish it from lookup/search sibling tools, though it does not explicitly contrast with cpu_find_buildings.

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 that the input is the catalog type 'as cpu_get_game_config lists it', giving a clear prerequisite for calling the tool. It also sets expectations that the result is organized into construction, operation, and lifecycle plans, but it does not explicitly say when to prefer this over sibling get/list tools.

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 full burden and does substantial work: it explains what is returned, defines distanceFromMine with null conditions, explains the storage box fields, and details the stalled flag's exact trigger and consequence. It could go slightly further by explicitly stating there are no side effects, but 'Inspect' plus the detailed semantics make the behavior clear.

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

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

The description is dense but purposeful: it front-loads the core action, then explains return shape and nuanced behavior, and ends with a routing pointer. Every major clause adds value, even if the stalled-flag explanation is fairly long.

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

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

For a read-only inspection tool with no output schema and no annotations, the description is unusually complete: it covers return contents, neighbor expansion, distance semantics with edge cases, resource storage fields, and process stall behavior. An agent has enough context to call this tool and interpret its response 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 already fully described in the schema ('The cell tokenId to inspect.'), giving 100% coverage. The description reinforces that the cell is the target and that ownership does not matter, but it does not need to add parameter syntax or format details beyond the schema.

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

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

The description opens with a specific verb and resource: 'Inspect one cell in depth' and clarifies the scope ('any owner — the map is public'). It also distinguishes itself from a sibling by pointing to cpu_get_map for broader awareness, making the tool's niche clear.

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

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

The description explicitly states when to use this tool ('Inspect one cell in depth') and names an alternative for broader context ('For broader situational awareness use cpu_get_map'). It does not enumerate exclusions against every sibling, but the scoping cue is sufficient for the main decision.

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 full burden, and it delivers: it explains that both bestListing and bestOffer are independently nullable, that neither null is an error, that trait/collection offers may have null tokenId but remain fillable, that prices are base-unit decimal strings, that times are Unix seconds, and that snapshots are about 10 seconds stale with repeated reads burning the read budget.

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 longer than average but every sentence earns its place: core purpose first, then sibling differentiation, then null semantics, then price formatting, then staleness and budget behavior. It is structured so the most decision-relevant information appears early and the details flow logically.

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 one parameter, a rich output schema, and the marketplace domain's complexity, the description is complete. It covers what is returned, how to interpret nulls, how offers vary by kind, how prices are encoded, snapshot freshness, and read-budget behavior, leaving no critical ambiguity for an agent invoking this 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 fully documents tokenId, including its decimal-string format and no-leading-zero rule, so baseline 3 applies. The description adds only 'one Cell per call' as extra semantic context, which is minor and does not compensate beyond the schema's already complete 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 states a precise purpose: return the NFT marketplace snapshot for one Cell, including the best active listing and best active offer. It also distinguishes this tool from cpu_get_markets and cpu_list_lots, which trade resources for $CPU, making it immediately clear what this tool is and is not.

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 names the alternatives it is separate from and why: cpu_get_markets / cpu_list_lots handle resource markets, while this tool handles the NFT land market. It also tells the agent to 'ask here' when ordinary map or Cell reads lack marketplace data, so the selection context is explicit.

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

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

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 the full burden of behavioral disclosure. It explains the stall condition (output box room less than one whole batch), the all-or-nothing settlement behavior, the meaning of isFinished (holds the process slot only), the reset of waiting, and the timestamp clock basis. It also notes the tool is public and works for any tokenId, which is important security/scope context. This goes well beyond a simple getter description.

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 structured with a front-loaded summary of what is returned, followed by necessary behavioral details. Each sentence earns its place: stall mechanics, isFinished semantics, timestamp clock, public access, and the pointer to cpu_claim_craft. There is no redundant or filler text.

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

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

Given there is no output schema and no annotations, the description does an excellent job of covering the complex craft-state concepts: schedule progress, claimable output, stalling, blocked outputs, finished runs, and timestamp consistency. An agent has enough information to interpret the response and decide next 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 coverage is 100% and the schema describes tokenId as 'the tokenId of the cell whose craft processes to act on,' so the baseline is 3. The description adds the extra semantic that the tool is public and works for any tokenId, clarifying authorization and ownership expectations 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 uses a specific verb ('Get') and names the exact resource ('the craft job on a cell') plus enumerates the returned data: recipe, status, batch progress, claimable amount, next maturation, and run end. This clearly differentiates it from sibling tools like cpu_craft and cpu_claim_craft, which initiate or bank craft jobs rather than report on them.

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

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

The description states this is 'the source of craft progress' and directs the agent to bank matured batches with cpu_claim_craft, giving a clear follow-up action. It implies when to use this tool versus the claim tool, though it does not explicitly mention when not to use it or compare with other status getters like cpu_get_mining_status.

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

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

With no annotations provided, the description carries the full behavior disclosure burden. It explicitly states 'Read-only' and 'No session needed', and describes the tool as delivering static facts read once, making its side-effect-free, idempotent nature clear. It also reveals a meaningful network behavior: how randomness is delivered determines what `cpu_reveal` does. No contradiction with annotations exists.

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 clause earns its place: core purpose is front-loaded, the listed data categories are all distinct and informative, and sibling routing is compactly included. It ends with short behavioral statements. Despite being a long paragraph, it is efficiently packed without 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?

Even though there is no output schema, the description explains the return contents in enough detail for an agent to know what to expect: resource mappings, contract addresses, parameters, building index rows with fields, and the tool's role in the rulebook. It also covers authentication context and side-effect safety, so nothing critical is missing for a no-argument read-only configuration getter.

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 and the schema already reflects this with 100% coverage and an empty properties object, so no parameter semantics are needed. The description correctly omits parameter details, and the baseline for a zero-parameter tool is 4.

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

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

The description clearly identifies the tool as the entry point for the static rulebook of the active network and enumerates its contents: resource catalog, contract addresses, storage shelves, transport parameters, transit fees, reveal cost, randomness mechanics, trade parameters, and a building index. It also explicitly distinguishes itself from siblings by stating that detail is not duplicated and pointing to `cpu_get_building`, `cpu_find_buildings`, `cpu_get_resource`, and `cpu_list_recipes` for fuller views.

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 guidance: it is the read-once source for static configuration facts, and it names alternatives with their specific scopes — a single building, searching buildings by consumption/production/mining, a single resource, and recipes. This directly tells an agent when to use this tool versus its siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states this is a public read, that it resolves lots in any state including evicted ones, and that only an 'open' lot is buyable. This meaningfully clarifies behavior beyond the schema, though it does not mention error cases or return format.

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

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

The description is compact: one sentence establishes the resource and returned fields, a second adds the key lifecycle nuance. Every sentence earns its place, and the most important information is front-loaded.

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

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

For a simple one-parameter read tool with no output schema, the description is complete. It specifies what fields the agent can expect, clarifies the operation is public, and resolves the important semantic ambiguity around evicted versus buyable lots. Nothing essential for calling this tool correctly is missing.

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

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

Schema description coverage is 100% and the only parameter, lotId, is documented as 'The lot id to inspect.' The description adds no new parameter semantics beyond restating that it operates by id, so it meets but does not exceed the baseline given the schema's completeness.

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

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

The description uses a specific verb and resource ('Inspect a single lot by id') and enumerates the exact fields returned (resource, remaining/listed units, price per unit, Hub location, seller, lifecycle state). It clearly distinguishes itself from sibling tools like cpu_list_lots and cpu_get_lot_terms by focusing on single-lot 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 gives clear context: this is a public read operation for inspecting any lot by id, even evicted ones. It also cautions that observing a lot is not the same as being able to buy it, which guides the agent away from using this tool to attempt purchases. It does not explicitly name sibling alternatives such as cpu_buy_lot or cpu_list_lots, but the usage context is clear.

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 behavioral burden and does so well. It explicitly says the operation 'Reads' data, notes that values are sourced from the Trade contract for the exact Hub/resource, and clarifies that a refused listing never costs approval or gas. It also discloses the counting semantics for live lots and evicted remainders.

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 every sentence earns its place: purpose, session requirement, return contents, data source, and cost safety. The key purpose is front-loaded in the first clause, and there is no filler 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?

Given no output schema and no annotations, the description is remarkably complete. It covers prerequisites, the conceptual return payload, the authoritative data source, and the safety guarantee around gas/approvals. An agent has enough context to invoke the tool correctly and interpret its results without additional documentation.

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

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

Schema description coverage is 100%, so the schema already documents hubTokenId as the Hub cell token id and resourceId as the resource type id. The description reinforces that the tool targets one exact Hub and resource but adds no meaningful parameter behavior 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 a specific verb and resource: 'Read the live terms for listing one resource on one Hub.' It also enumerates the precise outputs (min/max units, lots held, evicted remainders, canList verdict), making the tool's purpose unmistakable and distinguishable from siblings like cpu_create_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?

It clearly states when to use the tool: before spending anything to list, and it notes the session prerequisite (cpu_authenticate first). It also points to cpu_create_lot as the action that re-checks terms before spending. However, it does not explicitly address when not to use this tool or contrast it with other read/quote siblings.

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

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

With no annotations, the description carries the full burden, and it delivers: read-only nature, tokenId-based navigation without coordinates, neighbor semantics, empty=unminted, storage cutoff behavior, nullable cap semantics, scopes, time unit differences, and server.reachable implications. This is dense, honest behavioral disclosure.

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 information-dense; every clause adds value, especially given no annotations or output schema. It is front-loaded with the core action, though the single dense paragraph could be marginally easier to parse with light structural separation.

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

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

There is no output schema, so the description must explain returns, and it does: summary, resourceIndex, per-resource storage fields, epoch vs unix time, scopes, and failure behavior. For a complex 4-parameter tool with all-optional inputs, nothing essential 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%, so the schema already documents each parameter. The description adds a useful default nuance ("mine" vs "summary" if no wallet) and recontextualizes tokenIds within the map model, but most parameter meaning is already carried by the schema.

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

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

The description opens with a specific verb and resource: "Read the live game world." It then differentiates this tool from marketplace tools by explaining it is "land and storage, not the marketplace," making its purpose unmistakable even among many sibling tools.

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

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

The description explicitly directs when to use alternatives: "For offers use cpu_get_markets and cpu_list_lots" and points to cpu_get_attention for action items. It also clarifies scopes and defaults, so an agent knows how to select the right mode rather than guessing.

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 full disclosure burden and succeeds: it reveals the server-cached staleness, defines null price as 'no trades' rather than zero/free, explains that settled trades remain in the window even if the lot was later sold out/cancelled/evicted, and notes the spark series appears only in the JSON block. None of these behaviors are inferable from the schema or tool name.

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 purpose is front-loaded in the first sentence, and every subsequent sentence delivers a distinct, decision-relevant fact. However, at roughly eight sentences for a zero-parameter read tool, it is on the verbose side, and the 'never combined into one call' warning partially restates the cpu_get_markets differentiation from the previous sentence.

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 equips the agent to interpret the response fully: per-resource row structure, volume unit semantics, reading trends from changePct, null-price handling, and staleness limits. The explicit contrast with cpu_get_markets completes the selection context, so no further lookup is needed to call or interpret 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?

The tool has zero parameters, so the baseline is 4; the description explicitly confirms 'no inputs,' removing any ambiguity about invocation. There are no parameters for the description to elaborate on beyond that.

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 opening sentence states exactly what the tool returns — a world price index, one row per resource — and pinpoints the three metrics (24h volume-weighted average price in $CPU per unit, 24h percent change, 24h volume in resource units). It also actively distinguishes itself from the sibling cpu_get_markets by spelling out the different question each answers.

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

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

The description gives an explicit when-not-to-use rule: 'do not use it where you need second-fresh data' because it is a server-cached aggregate that can run an hour behind. It names the alternative (cpu_get_markets), explains the exact difference (cheapest ask right now vs what the world actually paid over the last day), and adds a hard exclusion — the two are never combined into one call.

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 full burden and does an excellent job: it discloses liveSaleFeePercent is advisory and may trail the chain, explains null semantics, clarifies that buckets count open/incoming/frozen offers, and states evicted lots are excluded. It also declares the read is public, covering safety without annotation support.

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 front-loaded: it opens with the core purpose, then covers caveats, routing, and bucket semantics. The first sentence is very long and packs many details into one parenthetical-heavy clause, but every sentence earns its place and nothing is 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?

Given there is no output schema and no annotations, the description compensates thoroughly by describing the row shape, key returned fields, filter/zone behavior, data-freshness caveats, and relationship to sibling tools. An agent has enough context to invoke the tool correctly with no arguments or with filters.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds some context by grouping hub/resourceId as filters and mentioning the optional zone (aroundTokenId + radius in grid steps), but this mostly restates schema information rather than introducing materially new parameter 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 the tool scouts the marketplace, enumerates the exact per-row fields (lot counts, lowest price, distance, sale-fee percent), and explicitly contrasts it with cpu_list_lots for drilling into specifics. The resource and scope are unambiguous, so an agent can distinguish it from sibling market-related tools.

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

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

It explicitly names cpu_list_lots as the follow-up drill-down tool and calls this 'the recommended first look at what is for sale and where,' giving both when-to-use and a clear alternative. It also notes the tool is a public read and supports filters, which helps an agent decide to invoke it without auth-related hesitation.

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 full burden, and it delivers: it explains that mining matures in whole cycles, that partial cycles bank nothing, that stalls begin before the box reads full, that isFinished means no further production, and that timestamps share the server clock. This goes well beyond a simple 'get status' phrase and makes the tool's runtime behavior predictable.

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 every major clause adds non-obvious operational knowledge, such as whole-cycle settlement, stall behavior, offload remedies, and isFinished semantics. It is front-loaded with the core read purpose, though the density of later sentences makes it slightly harder to scan than a shorter definition could be.

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

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

Given there is no output schema and no annotations, the description is remarkably complete. It covers the returned status fields, key behavioral edge cases, the public access model, time semantics, and the follow-up claim action. An agent has everything needed to invoke this tool correctly and interpret its 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 description coverage is 100% for the single tokenId parameter, and the schema already explains it as the cell to inspect. The description references cells generally but adds no new parameter-level semantics, 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 opens with a precise verb and resource: 'Read a cell's mining job', then enumerates exactly what is reported (active extractor, resource, yield, cycle length, progress, claimable units, stall state, end condition). This clearly distinguishes it from sibling action tools like cpu_start_mining and cpu_claim_mining.

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 clear usage context: it is public, works for any cell, requires no session, and uses unix timestamps aligned with serverTime. It also routes the owner to cpu_claim_mining for banking matured cycles and explains offload options when stalled. It does not explicitly state when not to use the tool versus named alternatives, but the context is strong.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses that the wallet is the authenticated one, there is no wallet input or way to read another player, pagination follows nextCursor, prices are strings needing currency context, each row carries orderHash for cancellation, and map/Cell reads lack marketplace data. These are behavioral details well beyond the schema.

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

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

The description is front-loaded with the core purpose, then moves through differentiation, pagination rules, price format, and cancellation data in a logical order. Every sentence carries operational value; there is no filler or redundancy. The length is justified by the number of critical behaviors an agent must know.

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 paginated authenticated listing tool with one parameter and an output schema, the description covers everything necessary: authentication scope, pagination mechanics, stopping condition, price representation, currency pairing, order cancellation, and the distinction from related reads. Nothing essential is missing, and the output schema supplies return-structure details.

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 describes the cursor parameter at 100% coverage, so the baseline is 3. The description adds important semantic detail by explaining that a page with fewer than 50 rows may still have another page, reinforcing both cursor reuse and the exact stopping condition. This extra context justifies a 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 opens with a specific verb and resource: 'Your own active Cell listings on the public NFT marketplace' and explicitly scopes it to 'the land you have put up for sale.' It differentiates itself from the sibling cpu_list_my_lots by clarifying that this is the land market, not resource lots, so an agent can immediately identify the correct 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 gives explicit when-to-use guidance: it states that ordinary map and Cell reads carry no marketplace data and that this tool should be used for marketplace listings. It also names the direct alternative, cpu_list_my_lots, and explains the distinction. Pagination usage is fully specified with stop conditions based on nextCursor, not row counts.

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 full disclosure burden, and it does so well. It explains pagination behavior (use nextCursor, stop only when nextCursor is null, never rely on row count), the string-typed base-unit amounts with currency decimals, nullable tokenId for trait/collection offers, and the presence of cancelable orderHash. These details go far beyond the schema and meaningfully shape how an agent should interpret results.

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 longer than minimal but is well-organized and front-loaded with purpose before moving to pagination and data-format caveats. Every section carries necessary warnings, though some cursor mechanics are repeated from the schema description. The structure earns a high score because each topic is distinct and useful.

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-only paginated query, the description covers the tool's purpose, its relation to a sibling tool, the exact authentication model, pagination termination rules, number formatting, and cancellation capability. The presence of an output schema further reduces the need to describe every field, so nothing essential 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 schema already documents the single cursor parameter thoroughly, so the baseline is 3. The description adds extra nuance beyond the schema by warning that a page with fewer than 50 rows may still have another page and that completion must be determined solely by nextCursor. That is a valuable addition that prevents a common pagination mistake.

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

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

The description names a specific resource and scope: active offers YOU made on the public NFT marketplace, specifically bids on land owned by others. It also distinguishes itself from the sibling tool by explicitly saying bids received on your Cells belong in cpu_get_my_offers_received. This leaves no ambiguity about what the tool returns.

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

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

The description gives an explicit when-not-to-use instruction: 'For bids other players made on your Cells, call cpu_get_my_offers_received instead.' It also notes that ordinary map and Cell reads carry no marketplace data, so an agent knows to request this tool rather than generic read endpoints. This is clear, actionable 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 the full disclosure burden, and it does so thoroughly. It explains pagination semantics (cursor omission, nextCursor reuse, null termination, page size caveats), amount formatting as strings, nullable tokenId for trait/collection offers, and the presence of orderHash. It also clarifies that the wallet is the authenticated one and there is no wallet input.

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 information-dense, with every sentence earning its place. It is front-loaded with the core purpose, then covers sibling distinction, offer-kind semantics, pagination, amount formatting, and the acceptance-relevant orderHash without unnecessary filler.

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

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

For a single-parameter read tool with an output schema and no annotations, the description is nearly complete. It covers authentication context, pagination, data types, nullability, sibling alternatives, and the purpose of each relevant field, leaving no obvious gap for an agent to call it correctly.

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

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

Although the schema already documents the cursor parameter at 100% coverage, the description adds significant operational meaning: omit cursor for first page, pass back the exact nextCursor, stop only when nextCursor is null, and never infer completion from row count. This goes beyond the schema's basic parameter description.

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

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

The description states a specific verb and resource: reading active offers received on the authenticated user's Cells from the public NFT marketplace. It clearly distinguishes itself from the sibling cpu_get_my_offers by explaining which tool covers offers you published yourself.

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 routes the user away to cpu_get_my_offers for self-published bids, and adds that ordinary map and Cell reads do not carry marketplace data, so this tool is the right place to query. This is clear when-to-use and 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?

With no annotations provided, the description fully carries the behavioral burden. It states the operation is read-only, requires no session, explains edge-case behavior ('A resource nothing touches answers with empty groups, not an error'), and clarifies scope boundaries like market price exclusion.

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 detailed, every sentence earns its place: it front-loads the tool's purpose, then systematically enumerates returned role groups, storage bounds, fee semantics, exclusions, edge cases, and access requirements. The semicolon-separated structure keeps the information dense but scannable.

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

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

Despite having no output schema and no annotations, the description tells an agent exactly what data to expect, how to interpret roles, what boundary constraints exist, and what happens in degenerate cases. It is complete enough for correct selection and invocation.

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

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

The input schema already describes resourceId fully: type, catalog id, example, and reference to cpu_get_game_config. The description repeats that same information without adding new parameter semantics, so baseline 3 is appropriate given 100% 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 states a specific verb and resource: returns everything the rulebook holds about one resource 'in one call.' It distinguishes itself from siblings by explicitly noting that market price is owned by cpu_get_market_index, and it defines the exact semantic categories returned.

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 when to use this tool: when you need all rulebook facts about a single resource. It also gives a concrete when-not/alternative: 'Market price is NOT here — cpu_get_market_index owns it.' It further guides invocation by pointing to cpu_get_game_config for the resource id.

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

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

With no annotations, the description carries full behavioral burden and succeeds. It discloses member ordering, pagination semantics, error behavior for unknown ids, empty page behavior, deliberate exclusions, and the public-read nature of the call.

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

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

The description is compact and front-loaded with the core purpose. Each sentence earns its place: returned data, ordering, pagination behavior, error semantics, exclusions, and alternative routing.

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

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

For a read tool with no output schema, the description is unusually complete. It explains the return payload, member page structure, ordering, error conditions, empty-page behavior, and what is intentionally omitted, giving an agent everything needed to invoke and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3. The schema already documents id, membersLimit, and membersOffset; the description adds behavioral context like ordering and empty-page results, but does not materially extend the parameter meanings beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Open one syndicate by id' and itemizes exactly what is returned (trusted card fields plus a page of members). It also distinguishes itself from the sibling cpu_get_syndicate_player_content by explicitly noting that player-authored fields are excluded.

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 clear context for when to use the tool: retrieving a syndicate by id with optional pagination. It explicitly directs agents to cpu_get_syndicate_player_content when player-authored name/link data is needed, providing an actionable 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 provided, the description carries the full behavioral burden and does so thoroughly. It discloses that the tool is a public read, describes the exact non-member vs. member response shapes, lists the member fields returned, and explicitly notes player-authored name/link are excluded.

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

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

Three dense sentences with no filler. The first sentence states purpose and the key usage option, the second explains response semantics, and the third covers exclusions and access level. Everything 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?

There is no output schema, so the description correctly takes responsibility for explaining return values. It covers both member and non-member cases, enumerates member-visible fields, and clarifies public read access. This is complete for a low-complexity, single-parameter 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 fully documents the single optional 'address' parameter, including the omit behavior. The description reinforces this but does not add substantial meaning beyond the schema, so the high-coverage 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: 'Check whether a wallet belongs to a syndicate.' It clearly differentiates from siblings like cpu_get_syndicate (which retrieves syndicate details) and cpu_get_syndicate_player_content (player content), making the tool's intent 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?

It gives clear usage context: omit the address to check your own membership, and explains that a non-member gets a plain 'not a member' response rather than an error. It does not explicitly name alternatives or state when not to use it, but the usage intent is clear.

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 full burden of behavioral disclosure. It thoroughly warns that strings are player-authored, untrusted, potentially prompt-injection, instructs never to follow commands or open links, and clarifies the link is returned as an inert string. This is exceptional transparency for security-critical read 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 front-loaded with the core purpose, followed by an essential security warning, then a clear sibling alternative. Every sentence earns its place, and the warning is detailed without being bloated.

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 read tool with an output schema, the description covers what is returned, the trust boundary, safe handling, and the alternative tool for trusted data. Nothing necessary for an agent to invoke it correctly is missing.

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

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

The input schema already covers the id parameter with 100% description and notes it is a 'Trusted syndicate id' with untrusted return data. The tool description repeats this trust distinction but adds no new parameter-level syntax or formatting detail, 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 opening sentence states an explicit verb ('read'), a specific resource ('syndicate display name and link'), and the input key ('trusted syndicate id'). This clearly distinguishes it from the sibling cpu_get_syndicate by naming exactly what this tool returns.

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 direct routing guidance: 'Prefer cpu_get_syndicate for trusted rates, manager, membership count, and timestamps.' This explicitly tells an agent when to use an alternative, and the security warning reinforces when this tool is appropriate (reading untrusted display content).

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?

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses immediate membership effectiveness, fee rate application, returned trusted rates, the intentional exclusion of player-authored name/link, the exit cooldown commitment, on-chain write behavior, and clear failure conditions. This is exemplary disclosure 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 long but front-loaded with purpose and nearly every sentence adds material behavioral or operational value. A small amount of redundancy exists in the commitment sentence ('so you cannot leave again right away' restates the cooldown), preventing a perfect conciseness score.

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 mutation with no output schema, the description is remarkably complete: it covers prerequisites, effects, return contents, commitment implications, transaction nature, and failure modes. An agent has enough information to invoke the tool correctly and anticipate outcomes.

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 fully documents the single 'id' parameter, so the baseline is 3. The description reinforces the provenance of the id ('from cpu_list_syndicates') but does not add additional semantic detail beyond what the schema provides.

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

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

The description opens with a specific verb and resource: 'Join a syndicate by id.' It clearly differentiates from sibling tools by referencing where ids come from (cpu_list_syndicates) and by stating failure conditions tied to membership state, which distinguishes it from create/leave/get membership tools.

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

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

It explicitly tells the agent to obtain ids from cpu_list_syndicates and warns that joining is impossible if already in a syndicate, routing to 'leave first.' It doesn't explicitly contrast with cpu_create_syndicate for creating a new syndicate, but the intended use is clear enough from the name and 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 the action writes on-chain (wallet transaction), fails clearly under specific conditions (not in a syndicate, registry not deployed), early attempts report the earliest leave time, and immediate rejoin is allowed. This is rich behavioral context beyond what a schema would 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?

The description is concise and front-loaded with the core action. Each of the four sentences adds distinct value: purpose, cooldown requirement, immediate rejoin, on-chain nature, and failure modes. No redundant or extraneous 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 parameters, no output schema, and no annotations, the description sufficiently covers operation behavior, constraints, failure modes, and consequences. It is complete for an agent to understand when and how to invoke the tool, especially with sibling tools like join_syndicate providing context.

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

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

The tool has zero parameters, so the schema is trivially complete. Baseline for 0 params is 4, and the description does not need to add parameter details. It confirms no inputs are required, which is sufficient.

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 with a specific verb ('Leave') and resource ('syndicate you currently belong to'). It is distinct from sibling tools like cpu_join_syndicate and cpu_create_syndicate, making its role 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 clear context on when to use: after the exit cooldown has elapsed, and notes that rejoining is immediately possible. It implies the alternative (join_syndicate) but does not explicitly name alternatives or mention when not to use beyond the cooldown. Failing conditions are specified, which helps the agent decide.

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 full burden and excels: it discloses the full multi-step side effects (approval, order preparation, local signing), the persistent setApprovalForAll grant affecting all Cells, fee deduction, retry safety, and failure behavior. This is exceptional transparency for a mutating marketplace operation.

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 and well-organized, front-loading the core purpose and then covering side effects, parameters, retry behavior, and result shape. Almost no filler, though it could be slightly trimmed without losing 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 complexity, the description is remarkably complete: it covers the full execution flow, approval consequences, fee split, retry idempotency, error condition, and result fields. With the output schema present, an agent has everything needed to call this tool correctly and understand its consequences.

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 adds meaningful semantics beyond the schema: price is explicitly 'GROSS' with mandatory fees deducted, buyerAddress reservation semantics, and the seller being the authenticated wallet. This enriches the parameter understanding without replacing the schema.

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

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

The description opens with a specific verb and resource ('Publish ONE Cell of yours for sale on the NFT marketplace'), immediately clarifying what the tool does. It also explicitly contrasts itself with cpu_create_lot ('sells RESOURCES for $CPU inside the game'), making its distinct purpose 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 clearly identifies the primary alternative (cpu_create_lot) and explains why this tool is different. It also gives concrete guidance on buyerAddress (reserve vs public) and when the call will fail (ACTIVE_ORDER_EXISTS). It does not enumerate all possible alternatives such as cpu_buy_cell or cpu_accept_cell_offer, but the core usage context is unambiguous.

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

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

No annotations are provided, so the description carries the full behavioral burden. It fully discloses that this is a public read-only feed, that paging is strictly one-way with a before cursor, that there is no reverse pagination or 'since' parameter, and that buyer/seller filtering is unsupported. This is comprehensive and directly useful for invoking the tool correctly.

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 every sentence carries essential operational information. Critical warnings like one-way paging and the absence of a 'since' parameter are front-loaded and emphasized, and the alternative-tool guidance is placed where it is most relevant. No filler or repetition exists.

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 and no annotations, the description covers purpose, filtering, pagination semantics, limitations, and alternative tools very thoroughly. The only notable gap is that it does not enumerate the exact fields returned in each fill row, but the cursor format and fill semantics are sufficiently described for an agent to page through 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 input schema already documents all four parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema: the 'before' cursor is explicitly tied to the last row of the previous page, omitting it reads the head, and filtering behavior is clarified in the context of the complete feed. This justifies a 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 identifies the tool as a feed of executed buys (fills), defines what a fill means, and distinguishes it from market asks. It also names the specific filter dimensions (resourceId, hubTokenId), so an agent can identify exactly what this endpoint returns.

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 tells the agent when to use this tool, how to pair it with cpu_get_markets, and when not to use it (e.g., for assembling your own trades, use cpu_list_my_lots). It also gives precise paging strategy, including how to detect new fills since the last read and why there is no 'since' parameter.

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 behavioral burden, and it does so thoroughly: it discloses this is a public read, explains that 'all' means open plus incoming and never sold/cancelled/evicted lots, notes that frozen lots are hidden under the default 'open', and mentions server clamping of radius to 50 and limit max 200.

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 clause earns its place: it front-loads the core purpose, packs the key parameters into one readable sentence, and finishes with routing and a critical exclusion case. No filler or repetition of schema text.

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

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

Despite no output schema, the description covers the important edge cases an agent needs before calling: availability nuances, evicted-lot exclusion, nearest/zone coupling, pagination bounds, and server clamping. For a complex 11-parameter, all-optional listing tool, nothing essential for correct selection and invocation 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%, so the baseline is 3, but the description adds real meaning beyond the schema: it clarifies that 'availability' defaults to open, defines 'all' precisely, ties 'nearest' to the zone requirement, and explains radius in grid steps with clamping. This extra semantic context justifies an above-baseline score.

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

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

The description states a specific verb ('Browse marketplace lots') and resource, then enumerates the filtering, sorting, pagination, and zone capabilities. It also explicitly distinguishes this tool from cpu_get_markets (compact overview) and cpu_list_my_lots (seller's evicted lots), so an agent can tell it apart without inspecting the schema.

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

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

The description gives explicit routing guidance: 'start with cpu_get_markets for a compact overview, then drill in here' and says an evicted lot never appears here, with the seller finding it via cpu_list_my_lots. It also explains the availability semantics (open, incoming, all) well enough to choose the right parameter value.

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 behavioral burden. It discloses that evicted lots are included by default, explains what evicted means, notes the session requirement, and shows how to isolate evicted lots with state=evicted. This goes beyond simple 'list' phrasing and reveals non-obvious 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 compact and front-loaded: purpose first, then usage, then a subtle behavioral exception. Every sentence earns its place, and the evicted-lot clarification is valuable rather than filler.

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

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

For a simple read-style listing tool with one optional parameter and no output schema, the description is sufficient. It covers session requirements, filtering, the default inclusion of evicted lots, and the intended use case, so an agent has enough context 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?

The input schema already documents the single optional state parameter with enum values, default behavior, and the evicted-lot nuance. The description adds no material parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate given 100% 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 uses a specific verb and resource: 'List the lots you have created' with an explicit lifecycle-state scope. This clearly distinguishes the tool from siblings like cpu_list_lots by emphasizing ownership ('my lots'), making the intended target 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?

It gives clear practical usage: 'Use this to find your lotIds and track listing and return progress.' It also states the precondition that a session is required. However, it does not explicitly mention when not to use it or name alternatives such as cpu_list_lots.

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 provided, the description carries the transparency burden. It discloses that only 'trusted facts' are returned, that player-authored content is deliberately excluded, and that this is a 'Public read.' It also enumerates exactly which card fields are returned, which is useful behavioral context.

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

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

The description is dense but efficient: it establishes purpose, enumerates filtering/sorting/pagination, lists returned fields, names the sibling to use for excluded data, and states access level. No sentence is wasted, though the many embedded clauses make it slightly heavy.

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 lack of an output schema, the description compensates well by naming the exact fields returned and clarifying the intentional exclusion and the alternative tool. It could additionally describe response envelope or pagination metadata, but the core calling context is adequately complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a convenient grouping of parameters into 'filter by name or member-count band, sort ..., and page with limit/offset,' but every parameter is already well documented in the schema with defaults and meaning.

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

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

The description opens with a specific verb and resource — 'Browse the syndicate registry' — and clarifies exactly what a syndicate is. It also distinguishes expected behavior from a sibling by noting that player-authored content is intentionally excluded and belongs to cpu_get_syndicate_player_content.

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 clearly conveys when to use this tool for browsing/filtering/sorting the registry and explicitly directs the agent to cpu_get_syndicate_player_content when player-authored name/link data is needed. It does not broadly compare against all syndicate-related siblings, but the main alternative is named.

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 thoroughly: it discloses the multi-step flow (duplicate check, reading the protocol counter, preparing the offer, sending approvals, waiting for receipts, signing locally, publishing), idempotent retry behavior, exact-amount approvals rather than open-ended allowances, and the returned status values. This is exemplary 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 but every sentence carries essential information about scope, process, parameters, or safety. It is front-loaded with the primary action and the key marketplace distinction, and the more detailed behavioral notes come after the core purpose is established.

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, lack of annotations, and the presence of an output schema, the description is complete: it covers what the tool does, how it differs from related tools, how parameters behave, what happens on retry, and what the result reports. Nothing critical is missing for an agent to invoke it correctly.

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

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

The schema already covers 100% of parameters, so the baseline is 3. The description adds meaningful semantics beyond the schema: amount must be a base-unit decimal integer STRING, currency is never passed in, the protocol counter is never passed in, and the offer is always for the exact named Cell. This earns an above-baseline score.

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: 'Bid on ONE exact Cell you do not own on the NFT marketplace, in a single call.' It sharply distinguishes the tool from siblings by clarifying it publishes a Cell offer, 'not a Lot and never a Fill,' and explicitly names cpu_create_lot as the separate resource-selling tool.

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

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

It explicitly states this is for the land/NFT marketplace and entirely separate from cpu_create_lot, which sells resources for $CPU in-game. It also says the tool 'never creates trait or collection offers' and that there is nothing to confirm afterwards, giving clear context for when to invoke 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 full burden. It discloses on-chain submission with confirmation wait, native ETH payment with drop-set per-cell price (possibly zero), no $CPU involvement, and that cells go to the connected wallet. This is rich behavioral context beyond any structured data.

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

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

Four sentences, each earning its place: purpose, pricing mechanism, prerequisites, and alternative. The description is front-loaded with the primary action and avoids filler.

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

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

For a one-parameter, no-output-schema tool with no annotations, the description covers prerequisites, price variability, balance check, confirmation behavior, and alternative market usage. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'quantity' cells but adds no parameter-specific semantics beyond the schema; it ties quantity to wallet and cost, which is more behavioral context than parameter meaning.

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

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

The description states a specific verb ('Mint'), resource ('new land cells'), and market ('primary market, straight from OpenSea SeaDrop public drop'), and contrasts it with secondary market listings. This clearly differentiates it from siblings like cpu_quote_mint and 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?

Explicitly instructs to read terms and total with cpu_quote_mint first and to verify cpu_get_balance covers total plus gas. It also names the alternative path for secondary market cells via OpenSea listings, providing both when-to-use and 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?

With no annotations, the description carries the full burden and fully delivers: it discloses read-only behavior, the exact reach formula, unfinished-Hub rules, fee behavior, empty hops semantics, the wall concept, and the requirement that the whole map be loaded. No contradictions with annotations exist because none were provided.

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 it is dense with non-redundant game rules and front-loaded with purpose and eligibility. A few sentences could be tightened, but the structure, including the labeled WHEN section, keeps the content navigable.

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

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

Despite having no output schema, the description enumerates the facts returned per candidate, covers edge cases like fromReady and empty hops, and establishes prerequisites such as map loading and caller-owned destinations. For a 4-parameter read-only survey tool, nothing essential appears missing.

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

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

Schema coverage is 100% and the schema already describes parameters well, so baseline is 3. The description adds meaningful nuance beyond that baseline by explaining 'towards' is a compass, not a route, by clarifying lotId changes only the origin, and by spelling out how resourceId drives per-unit fees.

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: 'Survey the legal next waypoints from a cell (read-only)', then explains eligibility and the reach rule in concrete terms. It also distinguishes itself from cpu_route_network and cpu_quote_transport by positioning itself as the cheap point check rather than a planner or verifier.

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 WHEN section is explicit: call before each leg and after cpu_get_changes shows movement, and fall back to cpu_route_network only when a local fix is impossible. It also gives clear alternatives for verification and for the lotId path, including cpu_quote_lot_return.

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 behavioral disclosure burden. It states that the tool takes no input, is meant to be read once, and describes the kind of content it returns. It could be more explicit about the return format, but for a simple briefing tool the behavioral context is reasonably complete.

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 entire description is a single, tightly packed sentence. It front-loads the purpose, lists the key content areas, and includes usage instructions without any filler.

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

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

For a zero-input, no-output-schema tool, the description is complete: it says what the tool is, what content it provides, when to read it, and how often. There is no missing information an agent would need to call it correctly.

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

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

There are zero parameters and the schema description coverage is 100%, so the schema already fully defines the input surface. The description reinforces this by saying 'No input,' which is sufficient. This meets the baseline for a no-parameter tool.

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

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

The description clearly identifies the tool as an operating brief for communicating with the operator, and enumerates exactly what it contains: voice, language rule, message shape, panel bar, and panel templates. It also explicitly says it requires no input, which distinguishes it from the many action-oriented sibling tools.

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

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

The description gives explicit instructions: read it once and do so before the agent's first reply to the operator. This is strong timing guidance and effectively tells the agent when this tool should be invoked relative to all other operations.

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 full behavioral disclosure burden — and it excels: read-only, reserves nothing, sends no tx, requires a session, returns detailed fields, re-runs buy checks, and explicitly lists what it does NOT check (pause, balance, allowance). It even discloses cpu_buy_lot's ~10% authorization headroom.

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 information-dense, and every sentence earns its place: behavioral constraints, routing modes, return fields, fee mechanics, failure semantics, limitations, and usage order. The most decision-critical facts ('read-only, reserves nothing, sends no tx') are front-loaded in the first sentence.

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

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

There is no output schema, so the description must explain return values — and it does, enumerating sale, saleFeePercent, discount, salePaid, tax, ownerNet, transitFee, transitDiscount, arrivalAt, and total. It also covers prerequisites, failure explanations, exclusions, and the relationship to the follow-on buy. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the chain parameter as the 'full preflight (sale leg + transit)' and tying it to the exact charge cpu_buy_lot would apply, plus clarifying the distinction between quoteSale-only and routed quotes. This goes beyond the schema's parameter 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 opens with a precise verb and resource ('Preview a buy priced by the Trade contract itself'), immediately marking it as a read-only preflight distinct from execution. It explicitly contrasts with cpu_buy_lot and details the mode selection ('full preflight' vs 'sale leg alone'), so an agent cannot confuse it with siblings.

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

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

It gives an explicit directive: 'Use before cpu_buy_lot.' It also explains when to include chain (full preflight) versus omit it (seller-only estimate), and clarifies what the quote does and does not check. This is strong, actionable guidance with clear 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 present, the description carries the full burden and does so thoroughly: it discloses that the call spends nothing, lists every output dimension, and explains the fee's role as a ceiling that cpu_return_lot may refuse to exceed. It also exposes the timing precondition, that the quote must be consumed immediately before the return, which is critical behavioral context.

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

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

The purpose is front-loaded, followed by preconditions, route requirements, output summary, and downstream usage in a logical order. Every sentence contributes distinct information, and the length is justified by the tool's relationship to cpu_return_lot and the need to define the fee ceiling behavior.

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

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

For a two-parameter tool with no output schema and no annotations, this description is nearly self-sufficient: it covers prerequisites, supported lot states, the exact required chain format, all returned information, and how to feed the result into cpu_return_lot. Nothing an agent needs to select and invoke the tool correctly is left to guesswork.

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

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

Schema description coverage is 100%, and the schema already documents both lotId and chain, including the required route structure and the recommendation to scout waypoints with cpu_next_hops. The description restates the chain format and lot ownership but adds no materially new parameter-level meaning, 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 opening sentence names a specific verb and resource: Preview sending one of your lots home — the whole unsold remainder, from its hub to a cell you own — without spending anything. It also names the paying counterpart cpu_return_lot, so the tool is immediately distinguishable as a quote rather than an 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 gives explicit when-to-use guidance: run this immediately before cpu_return_lot and pass the returned wei field back unchanged. It also states the applicable lot states (OPEN and EVICTED), the required session, and the exact required chain shape, leaving no ambiguity about how and when to invoke 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?

With no annotations provided, the description carries the full burden and does it well: it discloses read-only behavior, external data source (OpenSea SeaDrop), currency (native ETH), the possibility of a zero amount, and the returned fields. It does not mention error behavior or prerequisites, but for a single-optional-parameter quote tool this is solid coverage.

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

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

Two focused sentences, zero filler. The most important facts — no side effects, read-only, use before `cpu_mint_cell` — appear early, and every clause adds actionable information.

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

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

Given one optional parameter, no output schema, and no annotations, the description is complete: it defines what the tool returns, the units, the zero case, and the intended usage context. An agent has enough to decide when to call it and what to expect from the result.

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

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

Schema coverage is 100%, so the baseline is 3; the schema already documents `quantity` as a positive integer string with a default. The description adds that `quantity` cells are used to compute the total, but does not need to go further because the schema fully specifies the parameter.

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

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

The description states a specific verb ('preview'), the resource ('primary-market land mint'), and the key differentiator ('without committing... no side effects — no transaction'). It clearly distinguishes this quoting tool from the executing sibling `cpu_mint_cell` and other mutation tools.

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

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

Explicitly tells the agent when to use it: 'Use it before cpu_mint_cell to size the mint and confirm the drop is active.' It contrasts with the committing mint action and makes the intended workflow unambiguous. Naming the exact sibling it precedes is strong 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 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.