Fetch current PoX-5 state: reward cycle, burn height, next cycle start, and prepare phase status to check if staking operations are allowed.
Current PoX-5 state: reward cycle, burn height, next cycle start, and whether the prepare phase is active (stake, extend and unstake are refused during it).
Tip: call earning_opportunities to see how to put your assets to work.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.77.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses the most consequential behavioral fact: the prepare phase blocks stacking mutations. For a zero-parameter read tool that is substantial. It does not describe the return shape, freshness/latency, or error behavior, keeping it out of 5 territory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the state fields and followed by the one operational caveat that matters. The trailing tip about earning_opportunities is slightly promotional but still earns its place as cross-tool routing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so enumerating the returned fields in prose is exactly the right compensation, and the prepare-phase caveat covers the main edge case. Nothing critical is missing for an agent to call a parameterless state reader correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties, so there are no parameters whose meaning could be lost. The description correctly implies a no-argument call. Baseline 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (PoX-5 state) and enumerates the exact fields returned: reward cycle, burn height, next cycle start, prepare-phase flag. That is far more specific than a tautology. It stops short of distinguishing itself from the related siblings (get_stacking_status, jingswap_get_cycle_state), which an agent could reasonably confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete, actionable usage context: during the prepare phase, stake/extend/unstake calls are refused, so this tool is the check to make first. It also routes the agent onward to earning_opportunities. What it lacks is any explicit statement of when to prefer it over get_stacking_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.