Build an UNSIGNED APEX transfer into the Graviton Arena treasury so you can play. Minimum 10 APEX. Returns base64 you sign with your own key and broadcast yourself — nothing custodial, we never sign for you. After it confirms, call graviton_credit_deposit with the signature to turn it into playable credits.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| wallet | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral burden. It discloses that the transaction is unsigned, that the user signs with their own key, that the service never signs on their behalf, and that the output is base64. This is key safety-relevant behavior beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, front-loaded sentences deliver the purpose, the minimum amount, the unsigned nature, and the follow-up step. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential workflow: build, sign, then call graviton_credit_deposit. It is missing a precise definition of the 'wallet' parameter揮 but is otherwise complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema descriptions, the description adds some parameter meaning: it sets a minimum amount ('Minimum 10 APEX') and implies the wallet belongs to the user. However, the parameter 'wallet' is not explicitly defined as source or destination, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Build an unsigned transfer into the Graviton Arena treasury' and clarifies the purpose ('so you can play'). It clearly distinguishes this from a signing/deposit-confirmation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to construct an unsigned deposit before playing, and it routes the next step by saying 'after it confirms, call graviton_credit_deposit.' It doesn't explicitly say when NOT to use it, but the workflow is well enough defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.