cpu-game-mcp

by sodiqit

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.7.0
Disambiguation5/5
Each tool has a clearly distinct purpose with detailed descriptions that eliminate ambiguity. Even closely related tools like claim_craft and claim_mining are differentiated by their specific contexts.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, such as get_cell, list_lots, create_lot. There is no mixing of conventions, making it predictable for agents.
Tool Count4/5
37 tools is on the higher side but well-justified for a complex game with multiple subsystems (building, mining, crafting, trading, transport, etc.). The scope earns each tool's presence, though slight overabundance prevents a perfect score.
Completeness5/5
The tool surface covers the full lifecycle of game actions including authentication, building, mining, crafting, trading, transport, withdrawals, and quotes. No obvious gaps are present for the intended domain.
Average 4.5/5 across 37 of 37 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 52 commits in the last 12 weeks
- Last stable release on July 15, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It says 'Public read' suggesting read-only and no authentication needed, but does not explicitly state that the operation has no side effects or discuss rate limits or other behavioral details.
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?
Two sentences efficiently convey the tool's purpose and output contents. No redundant information, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description partially compensates by listing key returned fields. However, it omits some potential fields (e.g., lot ID, timestamps) and lacks behavioral guarantees, making it only moderately complete for the tool's 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?
Schema coverage is 100% with one parameter already described. The description adds output context but does not enhance parameter semantics 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 uses the specific verb 'Inspect' and identifies the resource as 'a single lot by id', listing key fields returned. This clearly distinguishes from sibling tools like cpu_list_lots which lists multiple lots.
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 for getting details on a specific lot but does not explicitly state when to use this over alternatives like cpu_list_lots, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 mentions 'Reads' implying no side effects, but does not disclose potential error conditions or permissions needed. Adequate but could be more explicit.
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 action and key results, with no wasted words. It efficiently conveys the tool's purpose and behavior.
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?
Without an output schema, the description lists the fields returned, providing good context. For a simple getter with one parameter, it is reasonably complete, though error cases are omitted.
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 documentation covers 100% of the parameter, including its source. The description adds no additional semantic value beyond what the schema already provides.
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 'Get one delivery by its on-chain deliveryId' and lists specific fields returned, distinguishing it from sibling tools like list_my_transports and 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 implicitly indicates a read operation ('Reads the deliveries projection') but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 mentions authentication ('Requires a session') and the scope of results ('across all lifecycle states'). However, it does not disclose whether results are paginated, sorted, or limited, nor any side effects. For a list operation, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant words. Front-loaded with the core action, followed by optional filter and use case. Every sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is mostly complete. It covers purpose, prerequisite, and use case. However, it omits the structure of the returned data (e.g., each lot object fields), which could be useful but is not critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full description for the single parameter 'state' (enum values and default). The tool description adds usage context ('track create / cancel progress') but doesn't enhance parameter semantics beyond the schema. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the lots you have created'. It specifies scope ('across all lifecycle states') and optional filtering by state. This distinguishes it from sibling tools like cpu_list_lots, which likely lists all lots, not just user's.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case: 'Use this to find your lotIds and track create / cancel progress.' It also notes a prerequisite ('Requires a session'). While it doesn't explicitly mention alternatives, the context of sibling tools implies it's for personal lots. Slight gap in excluding when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behaviors: inputs are debited upfront for all batches, most recipes start timer immediately, forge_wcpu requires on-chain payment and one-time allowance, and the run stops itself with no cancel. This is thorough for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main action. Every sentence adds value without redundancy. It is slightly long but efficient for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally mention what it returns (e.g., a craft ID or status). It only hints at follow-up tools. Error conditions or limitations beyond 'no cancel' are omitted. For a tool with three parameters and no output schema, some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 adds value by explaining behavioral context for parameters (e.g., 'batches' debited upfront and no cancel, 'recipeId' with special forge_wcpu cost). This goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the main action: 'Run a craft recipe on a cell you own (refine raw resources, or forge $WCPU).' It uses specific verbs and resources and distinguishes from sibling tools like cpu_list_recipes, cpu_get_craft_status, and cpu_claim_craft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: prerequisites ('call cpu_authenticate first'), discovery information ('discover recipes with cpu_list_recipes'), and follow-up tools ('cpu_get_craft_status' and 'cpu_claim_craft'). It also explains special cases like forge_wcpu costing $CPU. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It implies a read-only query (listing deliveries) and notes the returned fields, but does not explicitly state that it is non-destructive, requires authentication, or has rate limits. Additional context about side effects would improve 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 concise with two sentences. The first sentence states the main action and optional filters; the second adds detail on output and a practical use case. No unnecessary words, well front-loaded.
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?
The description covers the tool's purpose, output fields, and a typical use case (finalizing deliveries). It lacks information on pagination, sorting, or behavior if no deliveries exist, but these are minor for a simple list tool. Given no output schema, the description provides sufficient 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 describes the filter parameter with enum and default. The description adds value by integrating the parameter into the overall purpose ('optionally filtered') and listing the filter values in context. However, it mostly repeats schema info, so not a huge addition.
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'), identifies the resource ('ones you paid for'), and mentions optional filters. It also distinguishes from siblings by specifying it's for deliveries you paid for, contrasting with other list tools like cpu_list_lots.
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 explicitly advises using this tool to find deliveries to complete with cpu_finalize_delivery, indicating a primary use case. It mentions optional filters (all, in_transit, delivered, ready_to_finalize) but does not explicitly state when to avoid this tool or compare with siblings like cpu_get_transport_status.
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 provided, so description carries full burden. Discloses on-chain transaction, ETH fee requirement, free first reveal vs re-reveal conditions, asynchronous deposit behavior. Lacks details on failure modes or exact consequences of conditions not met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and well-structured, with main purpose first, then prerequisites, then fee and async details. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential workflow: authenticate, reveal (with ETH fee), async deposit, and reading with cpu_get_cell. Missing details on tool's return value and edge cases like insufficient ETH or re-reveal conditions, but still adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with clear parameter description. Overall description does not add new information about the parameter beyond what schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it reveals deposits of a cell you own. The verb 'reveal' and resource 'deposits of a cell' are specific. It distinguishes from siblings like cpu_get_cell (which reads after reveal) and cpu_authenticate (prerequisite).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: must call cpu_authenticate first, mentions asynchronous deposits and alternative tool cpu_get_cell for reading results. However, does not explicitly state when to use or avoid using this tool relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 in EVM mode it signs via SIWE and stores a token, while in AGW mode it returns a URL for user approval. It also explains force discarding the cached session. It does not describe error handling or return values, but the core behaviors are 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?
The description is concise at five sentences, front-loaded with the main purpose, followed by usage guidance, mode details, and parameter explanation. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the two authentication modes and usage scenarios, but lacks information about return values. For EVM mode, no output is described; for AGW mode, it mentions a URL but not what happens after user approval. This gap reduces completeness for an authentication 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 only parameter, force, has a schema description covering its purpose. The main description adds context on when to use force (e.g., after a game server reset), providing extra value beyond the schema. With 100% schema coverage, this additional context merits a score 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 clearly states the tool's purpose: 'Create a blockchain session.' It specifies when to call it (when other tools fail with authentication errors) and distinguishes between EVM and AGW modes. This sets it apart from sibling tools, none of which handle authentication.
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 explicitly says to call this tool when authentication errors occur, and explains the force parameter for discarding cached sessions. It provides clear context but does not explicitly state when not to use it; however, the error-driven guidance implies appropriate usage.
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, but the description states 'Public read,' confirming no side effects. It also notes that the server clamps radius to 50 and indicates defaults. This is sufficient transparency for a read-only browse tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in many details efficiently. It uses punctuation effectively to separate ideas. Slightly more structured formatting (e.g., bullet points) could improve readability, but it is still concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a browse tool with 11 parameters and no output schema, the description covers filters, sort, pagination, availability, and zone constraints. It also references a related tool for further context. Missing details like exact return format are compensated by the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 adds value beyond schema by explaining 'nearest needs a zone' and 'limit ≤ 200', and clarifying availability values. This helps the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for browsing marketplace lots with filters, and distinguishes from sibling tools such as cpu_get_markets (compact overview) and cpu_list_my_lots (own lots). The verb 'browse' and target 'marketplace lots' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear workflow hint: 'start with cpu_get_markets for a compact overview, then drill in here.' It also explains the availability default and alternatives (open, incoming, all). However, it does not explicitly list when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: atomic transaction, return path through waypoints, fee structure (foreign hub costs $CPU, otherwise free), gas payment, and the requirement to call cpu_finalize_delivery. It also mentions tracking tools.
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, each packed with essential information. No redundant or vague phrases. Front-loaded with the core action and then details. 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?
Given the tool's complexity (cancellation with return shipment, fees, multi-step process), the description covers all key aspects: prerequisites, parameter details, cost, follow-up action, and tracking. No output schema, but the result (return of units) is implied.
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 meaning: for 'lotId' it clarifies ownership ('must be yours'), and for 'chain' it explains the role of the first and last elements (hub and destination) and the fee trigger (foreign hub).
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 specific verbs ('Withdraw an OPEN lot') and clearly identifies the resource and action. It distinguishes from siblings like cpu_create_lot and cpu_buy_lot by focusing on cancellation and return of unsold units.
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 prerequisites ('Requires a session') and provides guidance on the required 'chain' parameter. It explains fee implications and the need to finalize delivery, but does not explicitly mention scenarios where this tool should not be used.
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 explains behavioral traits: mining matures in whole cycles, stall conditions, isFinished meaning, and that timestamps are Unix seconds on the server clock. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each sentence adds value, covering purpose, behavior, and related actions. It is front-loaded with the main action. 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?
Given no output schema and one simple parameter, the description provides a thorough explanation of the tool's output and behavior, making it complete for agent use.
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% for the single parameter tokenId. The description does not add additional semantics beyond the schema, so 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 specifies a clear action: 'Read a cell's mining job' and enumerates all the fields returned, distinguishing it from siblings like cpu_claim_mining and cpu_start_mining.
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 it's public and works for any cell without a session, and references cpu_claim_mining for the owner to bank cycles. It implies read-only usage but does not explicitly list when not to use it.
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 clearly states 'It has no side effects — no transaction,' which is essential for an agent to understand that this is a safe, read-only operation. It also mentions reading a live public drop, adding 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 extremely concise: two sentences that cover purpose, return data, side effects, and usage recommendation. Every sentence is useful and front-loaded.
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 the single parameter with full schema coverage and no output schema, the description is quite complete. It explains the return values and usage context. However, it does not mention error conditions or output format, but this is acceptable for a simple quote 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 input schema fully describes the `quantity` parameter. The description adds value by explaining that the parameter influences the output (total for quantity cells), which helps the agent understand how the parameter affects results.
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 primary-market land mint without committing' and specifies the exact data returned. It distinguishes itself from the sibling `cpu_mint_cell` by noting this is a preview 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 explicitly advises using this tool before `cpu_mint_cell` to size the buy and confirm the drop is active. It does not discuss when not to use it, but the guideline is clear and direct.
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?
Since no annotations are provided, the description carries full burden. It discloses all key behavioral traits: atomic tx, cost components (price, transit fee, gas), auto-approval with 10% headroom, delivery timing, and permission to buy own lot. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but each sentence adds value. It is front-loaded with the main action and then explains nuances. Could be slightly more concise, but overall well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers prerequisites, process, cost preview, auto-approval, delivery, and finalization. It mentions the returned deliveryId. Lacks explicit error conditions but is adequate for a buy tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 significant value: for 'chain' it explains waypoint structure and scouting via cpu_next_hops; for 'lotId' and 'value' it provides context on sources and constraints (positive integer, ≤ remaining).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Buy'), resource ('units from an OPEN lot'), and outcome ('delivered to your own cell'). It distinguishes from sibling tools like cpu_quote_buy (preview) and cpu_create_lot (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: when to buy (from open lot), prerequisite (needs session), and related tools (cpu_quote_buy for preview, cpu_finalize_delivery for completion). However, it doesn't explicitly state when not to use (e.g., if lot is closed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 that a configured wallet is required but no session needed. For a read-only operation, it provides sufficient behavioral context, including the return format (human-readable decimals).
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 concise sentences with no fluff. The first sentence explains what the tool shows and its format; the second adds usage guidance and requirements. Every word 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 simple parameterless tool with no output schema, the description is fully complete. It explains the output (balance in human-readable decimal), its purpose (before paid actions), and prerequisites (configured wallet, no session needed). No gaps.
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 has no parameters (0% param count, 100% coverage trivially). Baseline for 0 parameters is 4. The description does not need to add parameter info as there are none.
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 shows the wallet's spendable funds (CPU and gas balance) and explains what CPU is used for. The verb 'show' and resource 'wallet's spendable funds' are specific, and it naturally distinguishes from sibling action tools like cpu_build or cpu_swap.
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 guidance: 'Check this before paid actions to avoid failed or stranded payments.' This clearly indicates when to use the tool. It does not explicitly state when not to use or list alternatives, but the context is clear given sibling tools are for transactions.
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 behavior: stalling conditions, batch settlement rules, blocked output handling, isFinished implications, and timestamp reference to serverTime. No contradictions are present.
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 the main purpose and efficiently provides all necessary behavioral details in a well-structured manner without redundant or filler sentences.
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 lacking an output schema, the description comprehensively explains the output content (status, progress, claimable, timestamps) and key concepts (stalls, isFinished), making the tool fully understandable for an AI agent.
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 description adequately explains the tokenId parameter. The tool description adds minor context ('works for any tokenId') but does not significantly enhance the semantic meaning 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 uses specific verbs ('Get the craft job on a cell') and lists detailed attributes (recipe, status, progress, claimable, etc.), clearly distinguishing it from sibling tools like cpu_claim_craft by stating 'This is the source of craft progress; bank matured batches with 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?
It explicitly states the tool is public and works for any tokenId, and directs users to cpu_claim_craft for the claiming action. While it does not compare to other status tools (e.g., cpu_get_mining_status), the context is clear for its intended 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?
No annotations are provided, so the description carries full burden. It thoroughly discloses behavioral traits: atomic transaction, shipping goods, opening lot, gas costs, transit fees, sale fee freezing, delivery state, and return values. It also explains edge cases like rate raises and maxSaleFeePercent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured. It front-loads the main purpose and prerequisite, then details parameters and behavior. Every sentence adds value, but there is slight redundancy (e.g., mentioning tracking tools twice). Still, it is concise given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description is remarkably complete. It covers prerequisites, parameter semantics, process flow, edge cases (rate raises), and return values (lotId, saleFeePercent). It also mentions subsequent tracking tools, making it fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 adds significant meaning beyond the schema: it explains the chain structure (first node source, last hub), value as 'units to list', resourceId needing balance, pricePerUnit must be >0, and maxSaleFeePercent's effect. This elevates the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'List units of a resource for sale at a Hub, on-chain'. It uses a specific verb (list) and resource (units of a resource) and distinguishes this from sibling tools like cpu_buy_lot and cpu_cancel_lot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite: 'needs a session — cpu_authenticate first'. It also explains when to use the chain parameter and provides guidance on optional maxSaleFeePercent. However, it does not explicitly state when not to use the tool, though it is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses behavioral traits: it consumes resources (CPU and materials), preserves deposits and warehouse balances, and imposes a cooldown. It also explains restrictions and references other tools for exact costs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose. While slightly verbose, every sentence contributes necessary context. It balances detail with clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive, covering prerequisites, costs, restrictions, and outcomes. No output schema exists, but the description adequately explains what the tool does without needing to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, tokenId, is described identically in both the schema and the description. With 100% schema coverage, the description adds no additional meaning beyond what the schema already provides, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove the building from a Land cell you own, clearing it for a different building.' This is a specific verb+resource combination, and it effectively distinguishes the tool from siblings like cpu_build or cpu_buy_lot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides prerequisites ('Requires a session — call cpu_authenticate first'), costs, and conditions for use (no active mining or craft process, specific rules for mining extractor and hub). It also references alternatives like cpu_get_game_config for details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 items are descriptive ('suggest no action'), scouting is read-only, authentication needed for own cells, and potential unavailability of deliveries. It details flags and severity levels comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, starting with purpose then detailing flags and usage. While packed with information, some sentences are long; slight trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes return items (flags with severity, descriptive objects). It covers edge cases like deliveries down. The tool's complexity is well-handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaning: owner parameter scope (own vs scout) and minSeverity as urgency filter. It provides context beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Owner-scoped roll-up of cells worth attention, most time-sensitive first'. It distinguishes itself from siblings like cpu_get_cell or cpu_get_map by focusing on attention-worthy items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use ('so you skip scanning the whole map') and covers scoping (own cells vs scout another). It provides a note about deliveries endpoint downtime. However, it doesn't explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully details return values: cell, neighbours, distanceFromMine, resource storage box, and stalled flag condition, leaving no behavioral gaps.
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 front-loaded with purpose, then details; slightly verbose with parentheticals but generally efficient and clear.
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 provides comprehensive behavioral context, including special flags and references to a sibling tool, making it complete for decision-making.
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 description adds no additional meaning to the tokenId parameter beyond what the schema already provides; 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 'Inspect one cell in depth' with specific verb and resource, and distinguishes from the sibling tool 'cpu_get_map' for broader awareness.
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 this tool ('inspect one cell in depth') and when to use an alternative ('For broader situational awareness use cpu_get_map'), providing clear 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 provided, so description carries full burden. Discloses it's a public read operation, background-synced, and that pos is a rough hint. Mentions server.reachable flag indicating action viability. Could be improved by explicitly stating no authentication required and that it's a safe read.
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?
Description is dense but appropriately sized for the tool's complexity. Front-loaded with purpose and includes necessary details. Could be slightly more structured (e.g., bullet points) but remains clear and 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?
Given no output schema, description fully explains return structure (summary, resourceIndex, storage with details, timestamps, server.reachable). Addresses navigation, scope selection, and potential failure conditions. Comprehensive for a complex 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%, but description adds significant value beyond schema. Explains default scopes based on wallet presence, context for radius and aroundTokenId, and the meaning of 'around' scope. Provides behavioral context for parameters that enhances usability.
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 reads the live game world, using a specific verb ('Read') and resource ('game world'). It distinguishes itself from siblings like cpu_get_cell (single cell) and cpu_get_attention (to-do list) by mentioning them in context.
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 describes when to use different scopes (mine, around, cells, all, summary) and provides defaults. Also explains conditions for server.reachable false and directs to cpu_get_attention for to-do list, offering clear usage 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 discloses the on-chain submission and waits for confirmation, the ETH payment method, and the need for sufficient funds (mint price × quantity plus gas). However, it does not mention potential failure modes like network rejection, insufficient gas, or return value on success/failure.
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 paragraph that efficiently covers purpose, prerequisites, and alternatives. It is front-loaded with the core action and provides actionable steps. Minor improvement could be splitting into bullet points, but it is well-structured for 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 the tool has only one parameter, no output schema, and no annotations, the description provides a complete picture: what it does, how it works (on-chain, waits for confirmation), necessary preconditions (quote, balance check), and distinction from sibling tools (cpu_quote_mint for quote, OpenSea for secondary).
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 only parameter 'quantity' is fully described in the schema (100% coverage). The description adds context that cells are minted to the connected wallet and at the on-chain drop price, which goes beyond the schema's description of 'Number of land cells to mint'.
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 it mints new land cells on the primary market via OpenSea SeaDrop, paid in native ETH, and distinguishes itself from secondary market purchases by mentioning OpenSea listings. The verb 'mint' and resource 'land cells' are clearly specified.
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 clear when-to-use (primary market mint) and when-not-to-use (secondary market, use OpenSea listings). It also directs users to preview cost with `cpu_quote_mint` and check ETH balance with `cpu_get_balance` before calling.
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 states 'no side effects — no approval, no transaction.' This is explicit about the tool's behavior. Since no annotations are provided, the description fully covers the behavioral traits.
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, front-loaded with purpose. Every sentence adds value: purpose, behavior, usage advice. No wasted 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?
Given no output schema or annotations, the description provides sufficient context: what it does, what it returns (expected output and minimum), safety, and relation to sibling tool. It could be more specific about the return format, but it's 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?
Schema coverage is 100%, baseline 3. The description adds value by explaining that the output is 'already net of the pool fee' and that 'slippage' defines the minimum received. This goes beyond the schema 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 clearly states the verb 'Preview' and the resource 'ETH↔$CPU swap'. It specifies that it returns expected output and minimum after slippage, and explicitly distinguishes from 'cpu_swap' by noting no side effects.
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 explicitly says 'Use it before cpu_swap to size the trade.' This provides clear guidance on when to use the tool. It does not mention when not to use it, but the context is 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?
No annotations provided, so the description must fully detail behavior. It explains that rates only apply to new listings, not open lots, and can be set on a hub under construction. Also mentions revert conditions and return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative but slightly verbose (5 sentences). Key information is front-loaded, but could be more concise. However, it contains no wasted words and is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no output schema, and no annotations, the description covers all necessary context: prerequisites, parameter semantics, behavioral nuances, return value, and error conditions. Fully sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. Description adds minor context ('loop for several' for resourceId) but largely aligns with schema. Baseline score of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: setting a sale-fee rate on a Hub you own. It specifies the resource and lists the range (0-50, 0.01 granularity), distinguishing it from any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites: requires a session via cpu_authenticate. Provides guidance on looping for multiple resources, setting 0 for free, and reverts conditions. Clear when to use and what to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses important traits: costs no CPU, job is non-cancellable, holds process slot, cannot demolish mid-job, does not overrun, and effects on other operations. This is thorough and beyond the minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-organized, starting with the action and prerequisites, then explaining behavior. It could be slightly more concise, but every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all aspects: prerequisites, side effects (cell slot lock), scheduling advice, and references to related tools (cpu_get_mining_status, cpu_claim_mining). No output schema, but the return value is implied through tracking tools. Complete for a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions. The tool description adds context (e.g., 'batches is a commitment you cannot undo', 'omit targetResourceId when extractor mines a single resource'), enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Start a bounded extraction job on a cell you own that holds a finished extractor.' It uses specific verbs and resources, and distinguishes from siblings like cpu_claim_mining and cpu_get_mining_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions prerequisites: session via cpu_authenticate, cell ownership, finished extractor, and building construction. It also gives guidance on when to omit targetResourceId and advises checking cpu_get_game_config and cpu_get_cell beforehand. It does not explicitly list when not to use it, but provides sufficient context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details behavioral traits: debits source, pays fees, escrows delivery, returns deliveryId and arrival time, requires finalization. Lacks info on error handling or edge cases, but covers main effects well.
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?
Description is verbose but well-structured: starts with purpose, then flow, then constraints. Every sentence adds value, though slightly lengthy for a tool definition. Front-loaded with key action.
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, but description mentions return values (deliveryId, arrival time) and links to cpu_finalize_delivery and cpu_list_my_transports. Covers prerequisites, flow, constraints, and post-conditions comprehensively for a complex 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% with brief descriptions, but the tool description adds significant meaning: explains path constraints, hop distance rules, and references cpu_next_hops. Amount and resourceId are clarified 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?
Description clearly states 'Move a resource between cells along a waypoint chain of tokenIds', specifying verb, resource, and scope. It distinguishes from sibling tools like cpu_next_hops, cpu_quote_transport, and 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends a flow: cpu_next_hops → chain → cpu_quote_transport → cpu_transport. States prerequisite (session via cpu_authenticate) and conditions for fee and delivery. Provides 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 fully discloses behavior: debits the cell, mints $CPU, waits for confirmation, returns tx hash. It also mentions no approve needed and warns that wCPU is tied to the cell.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main action. It contains necessary detail but could be slightly more concise. However, it is well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description covers return value (tx hash) and suggests checking with cpu_get_balance. It includes prerequisites, constraints, and consequences, making it fully complete for a 2-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes parameters. Description adds value by providing examples (e.g., '100'), clarifying units ('whole wCPU units'), and referencing get_cell to check balance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Cash out a cell’s wCPU to the on-chain $CPU token'. It includes the resource ID, conversion rate, and prerequisites. Differentiates from siblings by being the only tool for converting wCPU to $CPU.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use (to convert wCPU to $CPU) and prerequisites: need a session via cpu_authenticate and own the cell. It warns about selling the cell. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behaviors: requires session, harmless no-op when nothing new, error on no extractor, cycle maturation rules, no interference with running jobs, and retirement of completed jobs. This exceeds expectations.
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 relatively concise given the complexity, and each sentence adds value. It is front-loaded with the main action. Slightly verbose but not wasteful.
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?
The description covers all key behaviors and refers to a relevant sibling tool. The only minor gap is no mention of return value, but its absence is acceptable given the action's side-effect nature.
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 description covers the parameter's purpose, and the tool description adds behavioral context (e.g., error conditions). With 100% schema coverage, the description enhances understanding 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: banking matured mining cycles into a cell's resource balance. It distinguishes from siblings by mentioning cpu_get_mining_status for checking available cycles.
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 prerequisites (session from cpu_authenticate), when it's a no-op vs error, and suggests checking with cpu_get_mining_status first. This provides clear usage 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 key behaviors: permissionless, on-chain (gas cost), crediting to target cell, and session requirement. It could be more explicit about error handling or if the operation is atomic, but the provided details are sufficient for understanding the core 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 highly efficient: two sentences covering purpose, prerequisites, and usage context. Every sentence adds necessary information without 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 simplicity (single parameter, no output schema), the description covers all necessary aspects: what it does, when to use it, prerequisites, and a pointer to the source of valid input. The return behavior is implicit (crediting to target cell) and adequately communicated.
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 describes the parameter 'ids' as on-chain delivery IDs. The tool description adds value by specifying that these come from 'list_my_transports' and must be for arrived deliveries, providing practical guidance 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 action (finalize), resource (arrived deliveries), and effect (crediting to target cell). It also distinguishes itself by noting it is permissionless and on-chain, and references a sibling tool for finding eligible deliveries.
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 specifies when to use the tool (only after arrival time has passed), prerequisites (requires a session via cpu_authenticate), and directs users to cpu_list_my_transports to check which deliveries are ready to finalize. It also notes the permissionless and on-chain nature.
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: version tracking, server reachability flag, and recovery actions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second explains usage and edge cases. No 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?
Given one optional parameter, no output schema, and no annotations, the description covers input, output hints, and error recovery 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?
Although schema coverage is 100%, the description adds practical meaning to 'sinceVersion' (pass from previous response, omit for full map). Baseline 3, additional value pushes to 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 clearly states 'Get only the cells that changed since a given version' with a specific verb, resource, and use case. It distinguishes from siblings like cpu_get_map by emphasizing incremental updates.
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 instructions on when to use (incremental updates), how to pass the version, and handling of server unreachability. Lacks explicit exclusions, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses it's a read-only operation ('free reference read') and indicates no session/auth needed. Could mention if any other side effects exist, but current disclosure is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficiently communicates necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description comprehensively covers return values (resource catalog, building catalog, reveal-cost params, addresses, recipe count) and points to sibling for full recipes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so baseline 4 applies. Description adds value by detailing the return contents beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the game rulebook for the active network' and enumerates specific components (resource catalog, building catalog, etc.), distinguishing it from sibling tools like cpu_list_recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'A free reference read — call it once to ground planning. No session needed.' and directs to cpu_list_recipes for full recipe graph, providing clear when/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals the tool is public (no session needed) and lists return details. However, it does not explicitly state idempotence or that it is free, though implied.
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: first describes function, second adds usage guidance and links to sibling. Every sentence adds value, 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?
For a simple list tool with no output schema, the description sufficiently explains what is returned (inputs, outputs, duration, CPU cost) and how to use it in workflow (before cpu_craft). No gaps.
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?
Input schema has 0 parameters (100% coverage by default). With 0 params, baseline is 4. Description adds no parameter info because none exist.
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 'List the craft recipes available in the game' with specific details (inputs, outputs, duration, CPU cost). It differentiates from the sibling cpu_craft by positioning itself as a preparatory 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 'Public — no session needed' and 'Use it before cpu_craft', providing clear when-to-use and access context. This distinguishes it from tools requiring authentication.
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, but description fully covers: read-only, no side effects, validation, surfacing rejection reasons. Discloses return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, each sentence provides value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param tool with no output schema, description covers return values, validation behavior, and integration with sibling tools. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions in schema are detailed. Description adds no new info beyond referencing `cpu_next_hops`. Baseline 3 per rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool previews a transport route without committing, returns fee/distance/timestamp, and distinguishes from `cpu_transport` (commits) and `cpu_next_hops` (scouts). Specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use this before cpu_transport' and 'Scout waypoints with cpu_next_hops', providing clear when-to-use guidance and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses all key behaviors: direction, exact-input, slippage handling, auto-approval via Permit2, on-chain submission with confirmation, and 1% fee. Thorough.
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?
Single dense paragraph with no wasted words. Logically flows from purpose to parameters to execution details. Every 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?
Covers all critical aspects: direction, parameters, preview requirement, token approval, on-chain execution, slippage, fees. No output schema needed as description explains outcome.
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%, but description adds context beyond like 'how much of the sold token to spend' for amount and 'floor on what you receive' for slippage. Clarifies slippage as percent and exact-input 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 the action (swap), resources (ETH and CPU), and context (game token pool on Uniswap v4). It distinguishes from sibling cpu_quote_swap by directing to preview first.
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 guidance to preview with cpu_quote_swap, explains when to set sell to ETH or CPU, and describes the exact-input nature. Lacks explicit when-not-to-use but is clear enough.
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 authentication requirement, mutation behavior (banking), error conditions (no craft processes), and slot freeing on full claim. This is comprehensive 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?
Three sentences, front-loaded with the primary action. Each sentence adds essential information without redundancy. Highly efficient.
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 annotations and no output schema, the description covers prerequisites, error states, and complementary tools. It could mention return values, but overall it is sufficiently complete for the moderate complexity.
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% with a single parameter (tokenId) described in schema. The tool description adds ownership context and clarifies that the cell must own craft processes, adding value beyond the schema description.
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 action: 'Bank every matured craft batch on a cell you own into its resource balance.' It distinguishes from siblings like cpu_craft and cpu_get_craft_status by specifying it is for claiming matured batches, not creating or checking.
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 conditions: requires a session via cpu_authenticate, describes no-op success vs error cases, and recommends checking claimable status with cpu_get_craft_status. This guides appropriate selection and invocation.
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 describes read-only nature, reach rules, hub states (fromReady), how fees are computed, and that empty hops indicate a wall. It fully discloses what happens in different scenarios.
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 thorough but somewhat long. However, every sentence adds value, and the key purpose is front-loaded ('Survey the legal next waypoints from a cell (read-only)'). Could be slightly more compact, but effectively structured.
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 is provided. The description explains exactly what is returned: hop distance, owner, hub flag, ready state, per-unit transit fee, and remaining grid distance if 'towards' is given. It also explains the meaning of empty list. Thorough for this 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%, setting baseline at 3. The description adds value by explaining that 'from' can be a cell or hub, 'towards' adds remaining grid distance as a compass, and 'resourceId' determines per-unit fee. This context goes beyond the schema 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 clearly states the tool 'surveys the legal next waypoints from a cell (read-only)'. It uses specific verbs and distinguishes from the sibling tool 'cpu_route_network' by noting that local planning is the user's job and that replanning via the sibling is only for when local fixes are impossible.
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 tells when to call: 'the cheap point check — call it right before each leg and after cpu_get_changes shows movement'. It also specifies when not to use and alternatives: 'replan via cpu_route_network only when a local fix is impossible' and explains that foreign cells are not waypoints.
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. It details read-only nature, node conditions (finished hub, own cells vs foreign), component IDs meaning, and edge radius formula. There is no contradiction with annotations as none exist.
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 dense paragraph but well front-loaded with purpose. Every sentence adds value, though it could benefit from slight structuring (e.g., bullet points) for easier parsing. Still highly concise for the amount of 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?
No output schema exists, so description must explain return structure. It fully describes nodes (owner, hub flag, ready state, fee, pos, component id) and edges (conditions). Also explains edge case like unfinished hubs. Complete for a complex topology 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 baseline 3. Description adds meaningful context: explains from/towards annotate with grid distances (potential field), resourceId shows per-unit transit fee. This enriches understanding beyond 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 road map of the world (read-only)' and explains it returns graph nodes and edges. It distinguishes from sibling cpu_next_hops by noting this is for heavy planning versus point checks. The verb 'route' and resource 'network' are specific.
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: the heavy read — plan a journey or a big replan; for point checks while executing use the cheap cpu_next_hops.' This provides clear when-to-use and alternative tool, which is exceptional.
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?
Fully describes read-only nature, no transaction, session requirement. Discloses transit fee re-quoting with ~10% headroom as ceiling, not extra charge. No annotations, so description bears full burden and does so excellently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose. Contains valuable details but is slightly lengthy; still every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers behavior, parameters, return values, and comparison to sibling. Completing the lack of output schema by describing returns. For a complex preview tool, it is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage). Description adds meaning by explaining chain as waypoints for transit fees, and returns (sale, transitFee, total) beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's a read-only preview for buying from a lot, reserves nothing, sends no tx. Distinguishes from sibling cpu_buy_lot by advising use before it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains two usage modes: with chain for exact total, without for seller-only estimate. Explicitly says 'use before cpu_buy_lot', providing clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 $CPU, auto-approves spend, sends on-chain, waits for confirmation, building takes time, cell holds one building, re-running on same building is safe no-op, need to demolish to switch, and a cooldown after demolish. It also tells what to do after building.
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 paragraph that is front-loaded with the core purpose and contains no superfluous information. Every sentence adds value, covering prerequisites, cost, behavior, and next steps. It is efficiently dense yet clear.
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 the complexity of the tool (blockchain interaction, multiple building types, dependencies on other tools), the description covers all essential aspects: prerequisites, cost, behavior, side effects (time delay, cooldown), limitations (one building per cell), and post-build actions. It mentions inspecting the result with cpu_get_cell, compensating for the lack of output schema.
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%, but the description adds significant meaning beyond the schema. For tokenId, it specifies 'revealed cell you own to build on'. For buildingType, it explains the categories (extractor, crafter, hub) and references cpu_get_game_config for the catalog, linking to sibling tools. This enriches the agent's understanding of parameter options and their implications.
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 'Place a building on a revealed Land cell you own' with a specific verb and resource. It distinguishes itself from siblings like cpu_demolish, cpu_start_mining, and cpu_craft, which are mentioned as subsequent steps or 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?
The description explicitly states the prerequisite of a session via cpu_authenticate, provides context for when to use the tool (after authentication, on a revealed cell), and explains when not to use it (re-running on same building is a safe no-op; need to demolish first to switch). It also references sibling tools cpu_get_game_config for the catalog and cpu_start_mining/cpu_craft for next steps.
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: public read, filters, zone, and limits of liveSaleFeePercent (may trail, null when unknown). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value; it is compact yet comprehensive, with no redundancy, earning its 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?
No output schema, but description specifies return structure: one row per (Hub, resource) with counts, price, distance, fee. Covers filters, zone, and data caveats, making it fully adequate for a first-look tool.
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?
Despite 100% schema coverage, the description adds meaning by explaining hub and resourceId as filters, zone as aroundTokenId + radius, and the advisory nature of liveSaleFeePercent, surpassing 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 scours the marketplace with specific fields per (Hub, resource) and distinguishes from sibling cpu_list_lots, fulfilling the 'specific verb+resource' criterion.
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 says 'The recommended first look at what is for sale and where' and directs to drill into lots with cpu_list_lots, providing when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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/sodiqit/project-cpu-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sodiqit/project-cpu-mcp)

Score Badge

Copy to your README.md:

[![project-cpu-mcp MCP server](https://glama.ai/mcp/servers/sodiqit/project-cpu-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sodiqit/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/sodiqit/project-cpu-mcp'

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