project-cpu-mcp

by projectcpu

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.8.1
Disambiguation5/5
Each tool targets a distinct resource/action pair, with clear patterns like quote_* vs execute, and get_* vs list_*. Even the many read tools (map, cell, changes, attention) have obviously different purposes, so an agent can reliably select the right one.
Naming Consistency5/5
All tools share the 'cpu_' prefix and overwhelmingly use verb_noun naming (get_*, list_*, quote_*, create_*, etc.). A few single-word verbs (build, craft, reveal) are still parallel and predictable, so the set reads consistently.
Tool Count2/5
With 49 tools, this is far beyond the typical 3-15 range and even exceeds the 25+ threshold that signals "too many". While the game has many subsystems, the sheer count makes the surface heavy to discover and navigate, even with good organization.
Completeness5/5
The tool set gives full lifecycle coverage: minting, building, mining, crafting, transport, marketplace, syndicates, swaps, and wallet operations all have corresponding actions with no obvious dead ends. Every major workflow—from quoting to executing to finalizing—is supported.
Average 4.6/5 across 49 of 49 tools scored. Lowest: 4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It states 'Public read,' indicating no side effects or auth requirements, and it describes the return contents (fee rates, member count, manager address, creation time). It stops short of noting potential empty results or default ordering, but for a read-only browsing tool this is strong coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, syndicate definition, feature list, return contents, and access level. It is front-loaded with the main action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates well by specifying the rendered card contents and covering all input dimensions (name filter, member-count band, sort, pagination). It does not detail the exact fee categories or response list format, but it is sufficient for a browsing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented individually. The description adds a grouping insight ('member-count band' for min/max members) and lists sort values, but it doesn't provide significant new syntax beyond the schema. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Browse the syndicate registry,' clearly stating a list/read operation for a specific resource (syndicates). It distinguishes from siblings like cpu_get_syndicate by using 'browse' and 'registry,' and it enumerates filtering, sorting, and paging capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (public read, browse all syndicates) but does not explicitly mention when to use this tool versus alternatives like cpu_get_syndicate for single-syndicate details. The 'browse' wording implies the list use case, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that this is a 'Public read,' that a non-member gets a 'not a member' answer rather than an error, and it details the exact return fields for a member (join time, earliest leave time, full syndicate card). This is strong behavioral transparency, though it does not cover edge cases like invalid wallet addresses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and efficiently structured: the first sentence states the core purpose, followed by two sentences that elaborate on the response behavior and return fields. Every sentence provides value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It covers the call pattern, the two possible response shapes (member vs non-member), and explicitly labels the operation as a public read. The agent has enough information to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single optional parameter is well-documented in the schema. The description adds the semantic of 'omit address to check your own,' which reinforces the schema description but does not introduce additional formatting or constraints. This aligns with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Check whether a wallet belongs to a syndicate.' It clearly distinguishes this from sibling tools like cpu_get_syndicate (which fetches syndicate details) and cpu_list_syndicates (which lists syndicates). The self-check option ('omit address to check your own') adds further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (checking membership for a wallet) and notes that omitting the address checks your own membership, but it does not explicitly state when to prefer this tool over alternatives like cpu_get_syndicate or when not to use it. No exclusions or alternative tool references are given, so the agent must infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses 'Requires a session', which is a key behavioral requirement, and notes that it covers 'all lifecycle states' with optional filtering. This adds useful context beyond the schema, though it does not describe behavior when no session exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, and includes the important session requirement and use case without any fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with no output schema, the description covers purpose, ownership scope, optional filter, session requirement, and an explicit use case. It implies the return includes lotIds, which is the main need. A minor gap is lack of detail on exact return structure, but that is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the `state` parameter fully documented including enum values and default. The description adds only 'optionally filtered by `state`', which duplicates the schema. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clearly scoped resource 'the lots you have created', distinguishing it from sibling tools like cpu_list_lots which presumably lists all lots. It also mentions lifecycle states and optional filtering, making 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use this to find your lotIds and track create / cancel progress.' The scope 'you have created' implies an alternative for viewing others' lots, but it does not name a specific alternative or explicitly state when not to use it. Still, clear guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly labels the operation as 'Public read', disclosing it's safe and requires no authentication. It also outlines the exact data returned, giving transparency into behavior beyond basic semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and resource, then efficiently lists the returned fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-with-ID tool, the description is complete: it states the action, the access level (public read), and the full set of returned attributes without relying on an output schema. It covers the essential context needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter lotId described as 'The lot id to inspect.' The description's 'by id' mirrors this and adds no new parameter-specific meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Inspect' and resource 'single lot by id', clearly distinguishing from sibling listing tools like cpu_list_lots and cpu_list_my_lots. It also enumerates the fields returned, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States this inspects a single lot by id, implying it's for when you have a specific lotId and need details. Doesn't explicitly name alternatives or exclusions, but the 'by id' wording vs list siblings provides clear context. 'Public read' also clarifies accessibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses 'Public read' (indicating a non-mutating operation), and explains that liveSaleFeePercent is 'enriched from the local world map — advisory, may trail the chain' and is 'null when the rate is unknown'. These are valuable behavioral caveats about data freshness and null semantics, though it does not mention pagination, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with 'Scout the marketplace'. It efficiently covers the output structure, usage guidance, and important behavioral caveats in under 80 words. Each phrase adds value, though the density of details makes it slightly more information-rich than a simple two-sentence description would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description thoroughly explains the return structure (one row per Hub/resource with counts, lowest price, distance, and fee) and the null/unknown fee behavior. It also covers all four parameters and provides usage recommendations, despite not mentioning ordering, pagination, or response size limits. This is complete enough for a read-only marketplace overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters, so the baseline is 3. The description adds only a light relational grouping by calling aroundTokenId and radius an 'optional zone', but it does not deepen understanding beyond what the schema already provides. This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Scout[s] the marketplace' and specifies the exact output: one compact row per (Hub, resource) with open-vs-incoming lot counts, lowest price, distance, and live sale-fee percent. It also distinguishes itself from the sibling tool cpu_list_lots by positioning this as the first look and that as the drill-down, so there is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is 'The recommended first look at what is for sale and where' and advises to 'then drill into specific lots with cpu_list_lots'. This provides clear when-to-use context and names an alternative, satisfying the 5-level requirement for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states 'Public read', which is an important safety trait. It also reveals the default availability behavior ('defaults to open') and implies that frozen lots are hidden by default via the schema. While it doesn't describe the exact response shape or error handling, the read-only nature and key defaults are disclosed, exceeding the minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that covers all essential aspects without redundancy. It front-loads the core purpose ('Browse marketplace lots') and each clause adds value. While it is slightly long, the density is justified by the tool's 11 parameters and the need to mention sibling tool and defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter list tool with no output schema, the description effectively covers filters, sort modes, pagination limits, optional zone, availability semantics, adjacency to a compact overview tool, and read-only nature. It does not describe the result object, but the tool name and sibling context make the return type (a list of lots) inferable. The description feels complete for practical invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 groups parameters into logical categories (filters, sort, pagination, zone) and highlights the availability default, but these details are already present in the schema. No new syntax or format information is added, so the description neither enhances nor detracts from the schema's parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Browse') and a clear resource ('marketplace lots'), and enumerates the key capabilities (filters, sort, pagination, zone). It explicitly distinguishes itself from the sibling cpu_get_markets by positioning this as the 'drill in' tool after a compact overview, making 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: 'start with cpu_get_markets for a compact overview, then drill in here.' It also specifies when to use different availability values ('use incoming for en-route lots or all') and notes that 'nearest needs a zone,' providing clear context for choosing parameters and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses exact-input semantics, slippage application as a floor, Permit2 auto-approval for CPU, on-chain submission and confirmation waiting, and the 1% pool fee. This is comprehensive and gives the agent a clear safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the core purpose and direction, then logically explains amount, workflow, slippage, approval, and fee. It could be slightly shorter, but the structure is clear and no information is redundant with the structured schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description covers all the important aspects of the swap: direction, amount, slippage, fee, and on-chain behavior. The only gap is that it does not describe the expected return value (e.g., transaction hash or receipt), which would help the agent know what to do with the result. Still, it is complete enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all three parameters have descriptions). The description reinforces the schema's meaning (e.g., `sell` directions, `amount` as spend amount, `slippage` as a percent) but adds little beyond what the schema already states. The Permit2 approval detail is behavioral, not parameter-specific, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Swap between native ETH and $CPU'), the resource ('game token pool (Uniswap v4)'), and supports both directions with explicit `sell` enum mapping. It also distinguishes itself from the sibling `cpu_quote_swap` by labeling that as a preview and this as the execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it tells the agent to preview with `cpu_quote_swap` first, implies this tool is for executing the actual swap after quoting, and explains the slippage and exact-input behavior. It does not explicitly mention alternatives or when not to use, but for a swap tool the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It thoroughly covers read-only nature ('public, background-synced'), world structure (48,990 cells, no coordinates), caveats ('pos is only a rough hint'), return contents, and failure signal ('server.reachable false means actions will fail'). This is exceptionally transparent for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the core purpose, then expands into necessary domain details. While it is a single long paragraph, it avoids redundancy and every clause adds value about the world, returns, or scopes. Minor structure improvements (bullets) would earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return structure (summary, resourceIndex, storage) and their semantics, provides navigation guidance, and warns about `server.reachable`. Combined with the schema's full parameter coverage, this gives agents a complete and actionable picture for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters with clear descriptions (scope enum, radius bounds, tokenIds requirement, aroundTokenId role). The description's scope list mostly restates schema info without adding new parameter-level meaning or clarifying dependencies beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Read the live game world.' It distinguishes this tool from siblings by detailing the world model (finite sphere, tokenId keys, navigation via neighbors) and the available scopes, making it unambiguous that this is the broad world-reader tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool ('Read the live game world') and implicitly contrasts with navigation via `cpu_next_hops` and action-related to-dos via `cpu_get_attention`. However, it does not explicitly state when not to use it or name alternatives like `cpu_get_cell`, so some inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses on-chain transaction, ETH fee requirements, free first reveal vs. costly re-reveal, dependency on network randomness mode, settlement behavior on self-service networks, and the fee-free nature of calling again on a pending reveal. This is comprehensive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence provides necessary operational detail—prerequisite, fees, re-reveal conditions, network dependency, and settlement behavior. It is efficiently structured, front-loaded with purpose, and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description explains key outcomes (returns deposits rolled on self-service networks, pending reveals) and important caveats (randomness mode, fee structure). It lacks a full return format specification, but given the simple single-parameter input and rich behavioral context, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter tokenId is already described as 'The tokenId of a cell you own to reveal.' The description merely reiterates 'a cell you own' without adding new parameter semantics, such as edge cases or format details, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Reveal the deposits of a cell you own.' It explicitly scopes to owned cells and distinguishes from related actions like re-reveal and pending reveals, making the tool's purpose unambiguous even with sibling tools like cpu_fulfill_reveal present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites ('call cpu_authenticate first'), resource requirements (ETH for fees), and situational guidance (when re-reveal applies, self-service network behavior). It does not explicitly name alternative tools or state when not to use it, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It explicitly states the action is IRREVERSIBLE, the tax stream transfers immediately, the only way to get it back is if the new manager transfers it back, and it lists clear failure conditions (not current manager, zero address, registry not deployed). This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but every sentence earns its place: purpose, irreversibility warning, caution to double-check address, on-chain nature, and failure conditions. It is well-structured with the main action first, followed by critical caveats. Slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an irreversible, high-stakes on-chain action with no output schema, the description covers all essential aspects: what it does, when it fails, consequences, and safety advice. It provides enough context for an agent to understand the impact and preconditions without needing to inspect sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (id and next) with 100% coverage. The description adds the consequence that the successor becomes the tax recipient, but the schema already states 'becomes the new manager and tax recipient.' Thus the description adds minimal semantic value beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Hand the manager role of a syndicate you manage to a successor wallet.' It uses a precise verb ('hand') and resource ('manager role'), and distinguishes this from sibling tools like cpu_set_syndicate_params by noting the irreversible transfer of manager role and tax stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool: when you want to transfer management to a successor. It also implies you must be current manager by stating failure conditions. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden and excels: it discloses the atomicity of the transaction, potential $CPU transit fee for foreign hub returns, gas costs, and the need to call cpu_finalize_delivery for crediting. It also clarifies that no crediting occurs until arrival, which is a key behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, front-loading the purpose and then covering requirements, fees, and post-steps without redundancy. Each sentence adds value, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description manages to cover prerequisites, process, fees, and next steps (finalize_delivery, tracking). It even implies the return of a deliveryId. It is complete enough for an agent to understand the workflow and necessary actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both params. The description restates the chain format and lotId ownership, adding little beyond the schema. While it mentions the fee implication, that's more behavioral transparency than parameter meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Withdraw an OPEN lot; the unsold units return to you, on-chain.' This is a specific verb+resource that distinguishes it from sibling tools like creating or buying lots. The on-chain detail adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: requires a session, requires chain for the return shipment, and mentions tracking with cpu_list_my_lots/cpu_get_lot. However, it does not explicitly state when not to use this tool or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and explicitly discloses 'It has no side effects — no transaction' and that it 'reads the live public drop.' This is transparent about the read-only nature. It could additionally describe edge cases (e.g., if drop is inactive), but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly two sentences, front-loaded with purpose, and every phrase adds value. No filler words or redundant information; the description is tightly written and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema). The description explicitly lists the return values (per-cell ETH price, total, drop window, per-wallet limit) and the use case (pre-mint sizing), making it complete for this request/response model. No annotations are needed because the description covers the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description references `quantity` in context ('total for `quantity` cells') but adds no new meaning beyond what the schema's description already provides. It reinforces the usage without expanding semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool previews a primary-market land mint without committing. It specifies the action (reads live OpenSea SeaDrop drop) and the exact outputs (per-cell ETH price, total, drop window, per-wallet limit), and distinguishes itself from cpu_mint_cell by naming it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use it before cpu_mint_cell to size the buy and confirm the drop is active.' This gives direct guidance on when to use and identifies the alternative execution tool, effectively covering the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 the on-chain mutation, the effect on seller proceeds, live applicability to open lots, the freezing behavior when tolerance is exceeded, the ability to set before hub readiness, revert conditions for ownership/rate bound, and the return value. This is comprehensive and goes beyond basic action description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence adds essential behavioral or contextual information. It is front-loaded with the primary action and prerequisite, then explains rate semantics, per-call limitation, live effects, construction state, and return. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (3 params, no output schema, no annotations), the description is remarkably complete. It covers prerequisites, rate mechanics, edge cases (tolerance freeze, under-construction), error conditions, and return value. There is no obvious missing context that would hinder an agent from using it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 tool description adds the note 'loop for several' for resourceId and restates the 0-100 bound, but it does not add meaning beyond what the schema already provides. The schema itself handsomely documents each parameter, so the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set the sale-fee rate for one resource on a Hub you own, on-chain.' It names the resource (Hub sale fee) and the scope (one resource), which distinguishes it from sibling tools like cpu_set_syndicate_params or cpu_buy_lot. The verb is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: 'needs a session — cpu_authenticate first', 'One resource per call (loop for several)', and 'Settable on a hub still under construction.' It also states an error condition for ownership. However, it does not explicitly mention alternatives or when not to use it, but given the tool's specificity, this is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full responsibility. It discloses the atomic transaction, the auto-approval of the sale and transit fee with ~10% headroom ('not a double charge'), delivery-only-after-arrival, the frozen-lot revert behavior, and the exact semantics of result fields (paid, tax, ownerNet). This is thorough 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with each sentence covering a distinct aspect (purpose, chain, cost, approval, delivery, frozen lots, own-lot rule, result). It is information-dense rather than redundant, though slightly more verbose than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex on-chain purchase with no output schema, the description is remarkably complete. It covers prerequisites (session), cost formula, fee drift headroom, delivery lifecycle, frozen-lot failure mode, and return-value semantics, all of which are essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with 100% coverage, including chain structure, lotId source, and value constraints. The description restates chain meaning but adds no new parameter-level semantics beyond what the schema provides, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Buy units from an OPEN lot, delivered to your own cell, on-chain' — clear verb, resource, and destination. It also distinguishes itself from sibling tools by explicitly referencing cpu_quote_buy for preview and cpu_finalize_delivery for completion, making this tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Preview the exact cost with cpu_quote_buy' and 'cpu_get_lot flags it up front' for frozen lots. It also outlines the post-purchase step requiring cpu_finalize_delivery, effectively telling the agent when to use this tool versus the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden and does so thoroughly. It discloses edge cases (no-op, error), cycle semantics (only whole cycles settle, wait resets if output doesn't fit), side effects (does not stop running job, retires completed jobs and frees process slot). This is exemplary behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then prerequisites, then edge cases. Every sentence provides non-redundant, necessary detail. Despite being longer than typical descriptions, it is dense with useful information and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description thoroughly covers prerequisites, side effects, and edge cases. It could explicitly mention the return value (e.g., new balance) to be fully complete, but the behavioral detail and pointer to cpu_get_mining_status make it nearly comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter (tokenId) with a description that already includes 'a cell you own with an extractor'. The tool description adds no additional param semantics beyond restating the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('bank') and resource ('matured mining cycle an extractor has produced on a cell you own'), clearly distinguishing it from siblings like cpu_get_mining_status (checking status) and cpu_start_mining (starting mining). It unambiguously states the action and its target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite ('Requires a session — call cpu_authenticate first') and advises checking availability with cpu_get_mining_status. It also differentiates valid claim scenarios (harmless no-op when nothing new, error on cells without an extractor), providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and delivers extensively. It discloses read-only nature ('pass `owner` to scout another player read-only'), wallet requirement ('Your own cells need an authenticated wallet'), item descriptive-only semantics ('suggest no action'), and fallback behavior when lookups fail ('remaining items still return and a `note` says so').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, front-loaded with the core purpose. It covers many flag types and edge cases without waste. A 5 would require tighter structure (e.g., bullets), but the complexity warrants the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description thoroughly explains the item structure (fields per flag type), severity levels, privacy scope, and degraded-mode behavior. It 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds extra meaning: for `owner`, it notes 'Deliveries are only surfaced for yourself'; for `minSeverity`, it explains the urgency ordering. This enrichment justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Owner-scoped roll-up of cells worth attention, most time-sensitive first'. This clearly distinguishes it from siblings like cpu_get_map and cpu_get_cell by focusing on prioritization rather than raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'so you skip scanning the whole map' and explains when to pass `owner` (scouting another player) and `minSeverity` (filtering). However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: payment in native ETH (not $CPU), minting to connected wallet, on-chain submission with confirmation wait, and need for sufficient balance. It doesn't describe the return value after confirmation, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with each sentence serving a purpose: purpose, cost preview, payment method, balance check, and secondary market alternative. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers usage, prerequisites, and alternatives thoroughly. It misses the return value after the on-chain wait, which would be useful, but overall it is quite complete for a single-parameter mint tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single 'quantity' parameter, so baseline is 3. The description adds meaning by relating quantity to the mint price and balance check, giving context beyond the schema's basic definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Mint new land cells on the primary market, straight from the collection’s OpenSea SeaDrop public drop'. It uses a specific verb 'mint' and resource 'land cells', and distinguishes itself from related tools like cpu_quote_mint and secondary market operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and alternatives: preview cost with cpu_quote_mint, check ETH balance with cpu_get_balance, and for secondary market use OpenSea listings. It also states prerequisites like having enough ETH for price × quantity plus gas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: on-chain execution, atomic debit, transit fee payment (auto-approved once), escrow with time-delayed delivery, hop radius constraints, and that goods credit only after calling cpu_finalize_delivery. It also mentions return values and fee waiver conditions. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well structured, front-loading the core action then layering prerequisites, constraints, and flow. It is longer than average but every clause adds useful information; could be slightly trimmed for conciseness but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description covers prerequisites, authentication, constraints, recommended flow, return values, post-conditions, and edge cases (e.g., own-cells fee waiver). It gives the agent everything needed to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats path constraints already in the schema and adds minimal new parameter-specific meaning; the additional context (fees, atomicity) is more about general behavior than the parameters themselves. It does not significantly enhance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Move a resource between cells along a waypoint chain of tokenIds', giving a specific verb, resource, and method. It clearly distinguishes from siblings like cpu_next_hops, cpu_quote_transport, and cpu_finalize_delivery by placing transport as the action that executes the move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit recommended flow: scout with cpu_next_hops, chain waypoints, verify with cpu_quote_transport, then execute. Also states when not to pay fees (own cells only) and prerequisites (session via cpu_authenticate). This offers clear when-to-use and alternative tooling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does so thoroughly. It discloses costs (burns $CPU, consumes build materials with no refund), preservation of deposits/warehouse balances, and post-effects (plot locked until demolish cooldown ends). It also surfaces edge cases like mining extractors and hub restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, every sentence earns its place: core purpose, prerequisites, cost mechanics, restrictions, and post-demolition behavior. The description is front-loaded with the main action and then expands into necessary caveats without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action with many edge cases, the description covers prerequisites, exact cost reference, restrictions, and post-demolition behavior. It lacks an explicit return-value statement, but with no output schema and side effects fully documented, this is acceptably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single tokenId parameter, describing it as a cell you own whose building to remove. The description adds no new parameter-specific semantics beyond restating the schema content, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Remove the building from a Land cell you own, clearing it for a different building.' This clearly identifies the tool's function and scope, and it distinguishes the tool from siblings like cpu_build or cpu_craft by focusing on demolition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite ('call cpu_authenticate first') and provides detailed when-not conditions: no active mining or craft process, hub cannot be mid-route or anchoring open trade lots. It also points to specific tools (cpu_get_game_config, cpu_get_cell, cpu_get_attention) for cost and cooldown details, giving clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it costs gas but no new reveal fee, it processes all open requests by default, settled requests are reported as success not errors, and it refuses on networks where manual settlement is unnecessary. This goes far beyond basic safety and covers edge cases and error semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph where every sentence and clause carries distinct value: core purpose, prerequisite, mode dependency, parameter behavior, and error handling. Despite its length, there is no fluff or redundancy; it is efficiently packed and front-loaded with the main action. It could be split into sections for readability, but its compactness earns top marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex interaction with network randomness modes and multiple argument paths, and no output schema. The description fully compensates by explaining prerequisites, alternative argument strategies, the distinction between settled and non-settled requests, and the refusal condition. It leaves little ambiguity about when and how to invoke the tool, making it highly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all three parameters, including tokensIds' behavior and requestId's bypass mechanism. The description adds context about the overall flow but doesn't meaningfully enrich parameter meaning beyond what the schema states, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 that have not delivered their draw yet.' It clearly distinguishes this tool from siblings like cpu_reveal by focusing on completing an already-opened request, and references cpu_get_game_config and cpu_authenticate to frame its unique role in the reveal flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'call cpu_authenticate first' establishes a prerequisite, and the description explains when to use it based on the network's randomness mode, even stating when it refuses ('On a network where the randomness source delivers draws itself this call refuses'). The argument variations (no args, tokenIds, requestId+source) are clearly tied to use cases, though no explicit alternative tool is named, the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes into depth about behavior: returns the cell, neighbours expanded as full cell states, distanceFromMine with BFS steps and null conditions, plus storage box contents and the stalled flag's precise trigger and effect on production. With no annotations present, this detailed disclosure fully carries the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses four sentences, each with a distinct job: purpose, return structure, field semantics, and a pointer to a sibling tool. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema, the description details the major return components and edge cases: neighbour expansion, distanceFromMine with null and 50-step limits, storage box fields, and the stalled flag behavior. This is comprehensive and actionable for a complex inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the only parameter tokenId is fully described with type, range, and purpose. The description adds contextual info ('any owner — the map is public') but no additional parameter syntax or format details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Inspect one cell in depth,' clearly stating the tool's action and target. It differentiates from siblings by explicitly pointing to cpu_get_map for broader awareness, making its narrow, deep-dive scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names an alternative tool: 'For broader situational awareness use cpu_get_map,' giving the agent a clear when-to-use versus when-to-use-something-else decision. It also notes that any owner's cell can be inspected since the map is public, setting expectations for access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses that mining matures in whole cycles (banking nothing mid-cycle), that stalls begin before the box reads full, that a stall burns time (schedule survives, wait does not), and that timestamps use the same clock as serverTime. This goes well beyond what annotations could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, every clause adds necessary behavioral nuance (stall mechanics, offload options, isFinished meaning, public access, timestamp reference). It opens with the core purpose and flows logically through return fields, edge cases, and related actions — no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of mining state and the absence of an output schema, the description is remarkably complete. It covers return values, timing semantics, stall conditions, what happens when finished, public accessibility, and indicates the companion claim tool — enough for an agent to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter tokenId is fully described in the schema (100% coverage, min/max, and a clear explanation). The description adds no additional parameter semantics, leaving the schema to carry the burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Read a cell's mining job' — a specific verb and resource — and enumerates exactly what data is returned (active extractor, resource, yield, cycle length, progress, claimable units, timing, deposit, stall status). It clearly distinguishes from sibling tools like cpu_start_mining and cpu_claim_mining by focusing on read-only status inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong context: it states the tool is public (no session required), explains when results indicate the job is finished ('isFinished' means nothing more will be produced, claim it), and points to cpu_claim_mining for the owner to bank cycles. It also mentions offload options to resume from a stall, giving practical guidance on when to use this status read versus acting on it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides key behavior: unknown id is an error, members page past end is empty, public read, and member ordering. It also discloses the return contents and pagination behavior, which is substantial transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all information-dense and front-loaded with the main purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 return payload (card fields and members page), error handling, ordering, and pagination. It's sufficiently complete for an agent to select and invoke this tool for a single syndicate lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions. The description adds context that members are ordered by joinedAt then address and that membersLimit/membersOffset page the member list, which is not in the schema. This provides extra meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens one syndicate by id and enumerates the returned card fields plus a members page. The singular 'one syndicate' plus the explicit id parameter distinguish it from list or membership sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific syndicate id and want its details and members. However, it doesn't explicitly name when not to use it or point to alternatives like cpu_list_syndicates for discovery or cpu_get_syndicate_membership for membership-specific queries, though the schema helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: membership effective immediately, fee rates apply from that moment, exit cooldown starts at join time, result reports earliest leave time, writes on-chain, and failure cases. This is far beyond minimal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and every sentence adds value: core action, immediate effects, commitment warning, on-chain nature, and failure conditions. Despite length, it is front-loaded with the primary verb and resource and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (commitment, cooldown, fees) and the absence of annotations and output schema, the description covers all essential aspects: input source, what happens on join, return value ('returned card', 'earliest time'), and when it fails. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the 'id' parameter as 'The syndicate id to join (from cpu_list_syndicates).' The description repeats this reference but adds no additional parameter-specific meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Join a syndicate by id' and specifies the resource and input source ('get ids from cpu_list_syndicates'). It distinguishes itself from sibling tools like cpu_leave_syndicate and cpu_get_syndicate by focusing on the join action and its immediate consequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: ids come from cpu_list_syndicates, and explicitly warns 'if you are already in a syndicate (leave first)' — a clear when-not. Also lists failure conditions for invalid ids and network issues, which helps the agent decide when 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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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 covers side effects (debits cell, mints $CPU), partial execution behavior, lack of approve requirement, session dependency, ownership requirement, and the fact that wCPU lives on the cell. It also explains result reporting (requested vs executed amounts) and confirmation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with the core purpose, then details parameters, behavioral edge cases, result handling, and a final warning. Every sentence adds value and no redundant information is present. It is concise yet comprehensive for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's two parameters, no output schema, and no annotations, the description provides a complete picture: prerequisites, usage, side effects, partial execution, result format, and related tools. It even anticipates a common misuse (selling the cell). No important aspect is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds extra meaning by explaining 'wCPU (resource id 1, the CPU Forge output)' and the 1:1 conversion, as well as the partial execution nuance. It also reminds to see the balance with `get_cell`, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cash out a cell’s wCPU... to the on-chain $CPU token in your wallet, 1:1'. It uses a specific verb ('cash out') and identifies the resource and conversion ratio, distinguishing it from sibling operations like cpu_swap or cpu_mint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (requires `cpu_authenticate` first, must own the cell), amount limits, and a caution about selling/transferring the cell. It also points to `cpu_get_balance` for verification. However, it does not explicitly discuss alternatives or when not to use this tool, leaving a small gap in the guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses costs ($CPU, possibly refined resources), auto-approval of spend, on-chain placement, waiting for confirmation, build time delay, single-building-per-cell rule, safe no-op on re-run, and demolition cooldown. This is rich behavioral context beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place, covering prerequisites, catalog, costs, timing, post-actions, and constraints. It is longer than typical but appropriate for a complex blockchain interaction; structure flows logically from placement to follow-up.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description covers the full lifecycle: authentication, building type selection, costs, waiting, activation, replacement, cooldown, and inspection. It even mentions the no-op case. No obvious gaps remain for an agent to invoke this tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both tokenId and buildingType, so the baseline is 3. The description adds meaning by categorizing buildingType (extractor, crafter, hub) and linking it to the game config and subsequent actions, which goes beyond the schema's enum list. It does not add new syntax for tokenId but reinforces the 'own' requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Place a building on a revealed Land cell you own', clearly distinguishing it from sibling tools like cpu_demolish and cpu_start_mining. It also enumerates building categories (extractor, crafter, hub), making the tool's function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: requires a session (cpu_authenticate first), references the catalog (cpu_get_game_config) for choosing buildingType, and explains follow-up actions (cpu_start_mining for extractors, cpu_craft for crafters). It also warns about the need to demolish before switching buildings and the cooldown after demolition, giving clear when-to-use and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it calls itself 'A free reference read' and states 'No session needed,' disclosing cost and auth requirements. It also explains that the randomness mode determines cpu_reveal behavior, adding useful context beyond a simple return-value list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long but dense sentence followed by a short call-to-action. Every clause adds value, though it could be easier to parse if split into a list. It is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 complete: it lists the rulebook contents, explains the relationship to cpu_reveal, directs to cpu_list_recipes, and states that it is free and session-free. This fully equips an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 instead elaborates on the returned data, which is appropriate; no parameter syntax is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the game rulebook for the active network, enumerating the resource catalog, building catalog, reveal-cost params, randomness delivery, contract addresses, and recipe count. It also distinguishes itself from siblings by mentioning cpu_list_recipes for the full recipe graph and how the result affects cpu_reveal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'call it once to ground planning' and 'No session needed' indicate when and how to use it. It also names an alternative, cpu_list_recipes, for the full recipe graph, helping an agent choose between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so exceptionally well. It discloses read-only nature, node/edge construction rules, hub states, foreign cell walls, component id meaning, bridging strategies, and the closed sphere. It goes far beyond typical descriptions in explaining edge cases and strategic implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense with relevant information. It is front-loaded with 'road map of the world (read-only)' and follows a logical structure. Some sentences could be tightened, but the verbosity is justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description enumerates node fields (owner, hub flag, ready state, fee, pos, component id) and edge rules. It covers hub construction states, foreign cell behavior, component meaning, and strategic use cases. This is more than sufficient for an agent to correctly invoke the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds valuable context: from/towards are for annotating distances 'to reason over', and resourceId determines the fee shown. Although the schema already describes the parameters, the description ties them to the map's purpose and strategy, slightly exceeding baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('road map of the world') and clearly identifies the resource (graph nodes/edges for movement). It distinguishes itself from siblings by explicitly saying 'Routing over this map is YOUR job' and comparing with cpu_next_hops and cpu_quote_transport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'WHEN: the heavy read — plan a journey or a big replan; for point checks while executing use the cheap cpu_next_hops.' It also tells the agent to verify via cpu_quote_transport, giving clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden and does so thoroughly. It discloses the switch cost behavior, free first pick/restart, no-cancel commitment, process slot locking, schedule never overruns, early end on dry deposit, and the need to wait for construction completion. This is rich, non-obvious 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each sentence adds unique value. It is well-structured: starts with the core action, then prerequisites, then parameters, then consequences and tracking. No fluff or repetition; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (no output schema, no annotations), the description is remarkably complete. It covers prerequisites, parameter semantics, edge cases (switch cost, dry deposit, process slot), and post-actions (tracking and claiming). An agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 significant meaning beyond the schema. For targetResourceId, it explains the switch cost and the omit-if-single-resource rule. For batches, it stresses commitment and sizing against cycle length and deposit, which the schema already hints at but the description enriches with strategic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Start a bounded extraction job on a cell you own that holds a finished extractor.' This clearly distinguishes the tool from sibling mining tools like cpu_claim_mining and cpu_get_mining_status by focusing on the action of starting a job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: requires a session (call cpu_authenticate first), references cpu_get_game_config for cycle lengths and cpu_get_cell for checking deposit/outputs, and points to cpu_get_mining_status and cpu_claim_mining for tracking and claiming. It doesn't explicitly state 'when not to use' but effectively covers the context and associated tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly describes side effects: banking into resource balance, freeing a slot when fully claimed, no-op success when nothing is matured, and errors when no craft processes exist. This is exceptional transparency for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: action, prerequisite, edge cases, and complementary tool. It is front-loaded with the core purpose and avoids any filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a claim operation with error cases, side effects, and prerequisites) and the absence of annotations and output schema, the description covers all essential context. It tells the agent about authentication, when the operation succeeds or fails, and what to check before calling, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for tokenId already states 'The tokenId of the cell whose craft processes to act on.' The description adds the ownership constraint ('a cell you own') and clarifies the action's context, which goes slightly beyond the schema. However, the schema coverage is high, so the additional value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Bank every matured craft batch on a cell you own into its resource balance.' This clearly states the action and its subject, distinguishing it from related tools like cpu_craft (creating batches) and cpu_get_craft_status (viewing status). It leaves no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: it requires prior authentication ('Requires a session — call cpu_authenticate first'), recommends checking claimable items first ('Check what is claimable first with cpu_get_craft_status'), and documents edge cases for when it is a no-op or an error. This tells the agent exactly when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It discloses that inputs are debited upfront, most recipes start timers immediately, forge_wcpu has a one-time unbounded $CPU allowance and waits for confirmation, switch costs are burned for recipe changes, and the result reports both costs separately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries useful information, but the single dense paragraph is long and somewhat rambling. It is front-loaded with purpose and prerequisites, yet tighter structuring could improve readability without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex execution tool with no annotations, no output schema, and 3 parameters, this description is remarkably complete: it covers prerequisites, recipe discovery, pricing checks, cost/approval details, switch behavior, timer semantics, progress tracking, and claiming.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds substantial meaning: 'batches' behavior (upfront debit, no cancel), the forge_wcpu auto-approval and cost specifics, switch cost semantics, and the requirement that the tokenId must be a cell the user owns. This goes well beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Run a craft recipe on a cell you own (refine raw resources, or forge $WCPU).' It clearly distinguishes this execution tool from related sibling tools like cpu_get_craft_status, cpu_claim_craft, and cpu_list_recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Requires a session — call cpu_authenticate first; discover recipes with cpu_list_recipes' and 'Check the price per recipe in cpu_get_cell (outputs) before you commit.' It also names the follow-up tools (cpu_get_craft_status, cpu_claim_craft), making the workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so richly: explains stalling condition (output box has room for less than one whole batch), settlement behavior (batches settle whole or not at all), reset behavior, meaning of isFinished, process slot hold, and timestamp convention. This exceeds typical status-read transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet well-organized, front-loading the core output then progressing to stall behavior, isFinished semantics, timestamp note, and final guidance. Every sentence contributes unique information; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description must explain return values; it does so by naming fields (completedBatches, batches, blockedResourceIds, isFinished, serverTime) and their semantics. Given the complexity of craft state, the description covers causes, effects, actions, and timing comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers tokenId with a clear description (100% coverage), so baseline is 3. Description adds meaningful context by confirming the operation works for any tokenId ('Public'), removing ambiguity about ownership restrictions, and tying tokenId to the cell context. This slight elevation above baseline is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with a clear resource 'craft job on a cell' and enumerates the returned details (recipe, status, progress, claimable amounts, timings). It distinguishes itself from sibling status tools like cpu_get_mining_status and cpu_get_transport_status by focusing on craft state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use: 'This is the source of craft progress' and explicitly directs to the next action: 'bank matured batches with cpu_claim_craft'. Also notes 'Public — works for any tokenId', clarifying access constraints. Provides clear context for interpretation of stalled states and recovery actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It states it is a 'Public read' (safe, no auth), explains one-way paging (newest first, `before` cursor pages down), the absence of a 'since' parameter, and how to read new data without paging down. It also clearly discloses the limitation on filtering by buyer/seller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries essential information: definition, semantics of fills, filtering options, paging rules, limitations, and alternatives. It is front-loaded with the core purpose, uses capitalization to highlight the paging note, and contains no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of annotations, and absence of an output schema, the description is remarkably complete. It explains what constitutes a fill, how to page correctly, how to use filters, what the tool cannot do (e.g., filter by buyer/seller), and how it relates to sibling tools. While it doesn't enumerate the exact output fields, it provides enough context about the cursor and semantics to make the tool usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has detailed descriptions for all 4 parameters (100% coverage), so the baseline is 3. The description adds extra meaning beyond the schema, particularly for the `before` cursor by explaining the one-way paging direction and the strategy of reading the head to detect new fills. It also clarifies that filters are optional and combinable, but does not add much for `limit` or `hubTokenId` beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'The feed of executed buys (fills) — what buyers actually PAID, not what sellers ask.' It uses a specific verb+resource and distinguishes itself from siblings like cpu_get_markets (asks) and cpu_list_lots (lots).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it tells when to pair with cpu_get_markets to compare asks vs. real prices, and directs users to cpu_list_my_lots for their own trades since this feed cannot filter by buyer/seller. It also explains how to page correctly and what not to do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully discloses read-only nature, the subtle 'fromReady' build-state quirk, hub construction implications (no reach/fee until finished), foreign cells as walls, and the meaning of empty hops. This goes far beyond basic safety to explain genuinely non-obvious behavioral semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-structured: purpose first, then mechanics, then planning responsibility, then when-to-use. Every sentence adds value, though the length (5+ sentences) prevents a perfect score. The 'WHEN' marker helps skimmability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema and no annotations, the description fully compensates: explains the reach rule formula, candidate facts, walls, hub building, fee behavior, and workflow integration. It covers edge cases (foreign cells, unfinished hubs) and gives actionable planning guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100%, the description adds critical meaning beyond field names: it explains that 'towards' is 'a compass, not a route,' clarifies that 'resourceId' determines the exact per-unit transit fee shown, and explains how 'from' being a hub or self-owned affects reach. This transforms dry schema definitions into actionable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: "Survey the legal next waypoints from a cell (read-only)." It clearly distinguishes this from siblings like cpu_quote_transport (which quotes transport cost) and cpu_route_network (which plans routes), while precisely defining the one-hop reach rule. This is a textbook example of a purpose that differentiates from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: "the cheap point check — call it right before each leg and after cpu_get_changes shows movement," and when to escalate: "replan via cpu_route_network only when a local fix is impossible." This is excellent guidance that maps directly to workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does so thoroughly: it discloses read-only behavior, no transaction, reserves nothing, needs a session, fee/burn allocation, the 10% headroom behavior of the follow-up buy, and the failure explanation semantics. This goes far beyond basic summaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, it is dense and well-structured: the first sentence gives the core purpose, then details flow logically through input semantics, output fields, fee allocation, caveats, and relationship to the buy tool. Every sentence earns its place and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 document return values, and it does: `sale`, `saleFeePercent`, `discount`, `salePaid`, `tax`, `ownerNet`, `transitFee`, `transitDiscount`, `arrivalAt`, and `total`. It also covers failure behavior and limitations, making the description complete for a complex financial preflight tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 valuable semantics beyond the schema. It clarifies that `chain` represents the full route and that omitting it invokes `quoteSale`, and it ties parameter behavior to the exact charge from `cpu_buy_lot`. This enriches parameter understanding without repeating schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Preview a buy priced by the Trade contract itself' and clearly contrasts with the execution tool `cpu_buy_lot`. It also differentiates from sibling quote tools like `cpu_quote_mint`, `cpu_quote_swap`, and `cpu_quote_transport` by focusing on the buy-lot sale leg and optional transit routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use before `cpu_buy_lot`' and provides precise when-to-include-chain guidance: full preflight with `chain`, or omit for a seller-only estimate. It also states what the quote does NOT check (pause, balance, allowance), helping the agent avoid relying on it as a complete guarantee.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states that the operation REPLACES the entire card, that omitted fields revert to defaults, that it writes on-chain (a wallet transaction), that manager and creation time are untouched, and lists all key failure conditions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the critical warning ('This REPLACES the entire card at once'), then gives the safe workflow, then lists constraints and failure modes. While long, the structure is logical and no information is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers prerequisites, behavior, constraints, and error conditions comprehensively. It even suggests the verification step (read with cpu_get_syndicate FIRST). The only minor omission is the exact return value on success, but that is not critical given the detailed behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage, so the baseline is 3. The description adds value beyond the schema by explaining that omitted fields revert to defaults and that rates are converted to basis points on-chain. It also reinforces that id comes from cpu_get_syndicate, which is useful context. This pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update a syndicate you manage,' which is a specific verb+resource pair. It clearly distinguishes from siblings like cpu_create_syndicate, cpu_transfer_syndicate_manager, and cpu_get_syndicate by emphasizing that it replaces the entire card rather than performing a partial patch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Read the current card with cpu_get_syndicate FIRST and resubmit the full state with your edits applied.' It also warns against using it when not the manager ('Fails clearly if you are not the manager') and explains the danger of partial updates. This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the authentication flow (SIWE in EVM, URL approve in AGW), token storage, automatic subsequent tool behavior, and force parameter's effect. This is rich behavioral context beyond a simple 'authenticate'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a one-sentence purpose, usage condition, mode behaviors, and force explanation. No filler; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema) and abundance of sibling tools, the description adequately covers purpose, usage triggers, mode-specific behaviors, and edge cases. It is a complete standalone explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter `force` is already described in schema, but the description adds a concrete scenario ('after the game server was reset and the stored token references a stale user'), enhancing understanding beyond schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a blockchain session' as the core function, using a specific verb and resource. It distinguishes itself from sibling tools by focusing on authentication/session setup rather than game actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this tool when other tools fail with authentication or session errors', providing clear when-to-use guidance. Also clarifies force=true usage for stale sessions, and mentions both EVM and AGW modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: atomic transaction, state transition from DELIVERING to OPEN, fee mechanics (transit fee, hub sale fee), freezing condition when the hub raises its fee above tolerance, and that `cpu_cancel_lot` is always fee-free. It gives concrete details on what happens to the lot and escrow, going far beyond any structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries essential information for a complex tool. It is front-loaded with the main purpose, then efficiently covers mechanics, fees, states, and return values. There is no fluff; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5-parameter complexity, no annotations, and no output schema, the description is remarkably complete. It explains return values (lotId and locked-in `maxSaleFeePercent`), the delivery finalization step, related tracking tools, and all fee/freeze edge cases. Nothing essential is missing for a competent agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already covers 100% of parameters, the description adds substantial contextual meaning beyond the schema. For `chain`, it explains the source-to-hub route and foreign hub fee; for `maxSaleFeePercent`, it details the tolerance, locking behavior, and freeze conditions; for `value` and `pricePerUnit`, it ties them to the sale fee model. This is added value, not redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'List units of a resource for sale at a Hub, on-chain.' It distinguishes this from sibling tools like cpu_buy_lot and cpu_cancel_lot by focusing on the creation of a sell lot with atomic shipping, and it explains the overall operation. The scope is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a prerequisite (needs `cpu_authenticate` first), explains when to use it (to list units at a hub), and references alternatives and follow-ups: `cpu_finalize_delivery`, `cpu_cancel_lot`, `cpu_list_my_lots`, `cpu_get_lot`. It also clarifies the transit fee condition and the hub fee tolerance, giving a complete usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: server-cached aggregate up to an hour behind, null price meaning 'no trades' not zero/free, and spark series only in JSON not text summary. These are critical semantics 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though longer than typical descriptions, every sentence earns its place: it front-loads the core purpose, then adds necessary caveats, output formatting details, and sibling differentiation. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 exceptionally complete: it covers all return fields, memory of spark series location, null semantics, caching latency, and comparison with the sibling tool. The tool's simplicity (no params) is fully addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so baseline is 4; the description adds meaningful context about the output structure (one row per resource, volume in units not $CPU) and confirms no inputs needed. This goes beyond the minimal baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a world price index with specific metrics (24h volume-weighted average price, percent change, volume in resource units) and explicitly distinguishes it from sibling tool cpu_get_markets by contrasting 'what the world actually paid' vs 'cheapest ask available right now'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: not for second-fresh data due to server caching, and directly names the alternative tool (cpu_get_markets) with a clear explanation of the different question each answers. Also warns against combining them into one call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It clearly states 'Read-only on-chain view with no side effects,' details the return values including fee/discount semantics, and explicitly mentions validation behavior and rejection reasons for invalid routes. No annotation contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured to front-load the primary action ('Preview... without committing'), then efficiently details outputs, side effects, validation, and usage context. Every sentence contributes unique information, and no redundant or filler content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters and no output schema, the description covers the purpose, return values, edge cases (invalid route), and references to sibling tools (cpu_next_hops, cpu_transport, get_game_config). This is sufficient for an agent to select and invoke the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds significant meaning beyond the schema. It explains the concept of a waypoint chain, hop radius constraints, the relationship between fee and discount, and how parameters map to on-map resources. This goes well beyond the baseline of 3 for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Preview a transport route... without committing' and enumerates the specific outputs (fee, discount, distance, timestamp). It also distinguishes itself from siblings by explicitly positioning it as a pre-commit validation step before cpu_transport, alongside cpu_next_hops for scouting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Scout waypoints with cpu_next_hops; use this before cpu_transport.' This tells the agent exactly when to invoke this tool relative to alternatives, and the validation/error-surfacing behavior clarifies when it is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![project-cpu-mcp MCP server](https://glama.ai/mcp/servers/projectcpu/project-cpu-mcp/badges/card.svg)](https://glama.ai/mcp/servers/projectcpu/project-cpu-mcp)

Score Badge

Copy to your README.md:

[![project-cpu-mcp MCP server](https://glama.ai/mcp/servers/projectcpu/project-cpu-mcp/badges/score.svg)](https://glama.ai/mcp/servers/projectcpu/project-cpu-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/projectcpu/project-cpu-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server