network_emission
Block reward / emission time series (XMR per block). window in 1h,24h,7d,30d,90d,1y,5y.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Time window, one of 1h, 24h, 7d, 30d, 90d, 1y, 5y. Example: 30d | 30d |
Block reward / emission time series (XMR per block). window in 1h,24h,7d,30d,90d,1y,5y.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Time window, one of 1h, 24h, 7d, 30d, 90d, 1y, 5y. Example: 30d | 30d |
Changes observed during successful MCP inspections.
Input schema / properties / window / descriptionAdded value: +"Time window, one of 1h, 24h, 7d, 30d, 90d, 1y, 5y. Example: 30d"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds only the emission unit (XMR per block), a data-semantics detail; it says nothing about the shape of the series, sampling granularity, or the default window behavior beyond what the schema carries.
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 short sentences, front-loaded with what the tool returns and followed by the accepted window values. The only waste is the window enumeration, which duplicates the schema verbatim.
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?
This is a simple single-parameter read tool, so the definition is close to adequate, and the unit annotation compensates somewhat for the missing output schema. Still, with no output schema the description could have sketched the return shape (timestamps plus values, array of points) to remove ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already lists the allowed window values and the '30d' default. The description restates the same enum list, adding no syntax, format, or interpretation guidance beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('Block reward / emission time series') and even gives the unit (XMR per block), which is enough to distinguish it from siblings like network_hashrate, network_blocktime, and price. It falls short of a 5 because it never explicitly contrasts itself with any of those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no named alternative. An agent must infer from the resource name alone that this is the tool for emission/reward history rather than, say, price or network_info, and nothing tells it when this series is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.