Live Monero network metrics: reorgs, orphans, pool centralization and the Haveno order book.
Scored across 19 tools
Most tools have clearly distinct targets: chain reads, network time series, pool attribution, reorg tracking, and Haveno P2P data are all separable from names plus descriptions. The weak spots are get_block vs search_block (search_block with a hash returns essentially the same block detail) and some adjacency between chain_fork_window, recent_orphans and reorgs/reorg_stats. Descriptions do spell out the differences, but a couple of pairs invite misselection.
Everything is snake_case and reasonably readable, but the set mixes several conventions: verb-first actions (get_block, search_block, lookup_transaction), noun-prefixed series tools (network_*, pool_*, haveno_*, chain_*), and bare nouns (price, reorgs, recent_orphans). The domain prefix acts as a loose namespace, yet there is no single predictable verb_noun pattern across the set.
At 19 tools the server spans two large domains (Monero chain/network analytics and Haveno P2P market data), so the breadth is justified rather than padded; each series tool covers a distinct metric. It is on the heavy side of comfortable, and get_block is arguably a redundant fifteenth-plus tool, but nothing feels like filler at scale.
Coverage is broad and coherent for the domain: blocks by hash and height, transactions, mempool, hashrate, emission, block time, pool distribution/provenance/health, orphans, reorgs and aggregate stats, plus spot price and Haveno book/premium/payment-method data. Minor gaps remain, notably no historical centralized price series (only current spot and Haveno premium history) and no difficulty or fee time series beyond current network_info.
Canonical chain plus any competing orphan blocks around a height. 'to' is the highest height in the window (defaults to the current tip); lower it to browse older history down to the genesis block. limit 10..500.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Highest block height of the window; omit for the current tip. Example: 3000000 | |
| limit | No | Number of heights in the window, 10 to 500. Example: 100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds substantive context beyond them: that results mix canonical blocks with competing orphans around a height, and that the window is anchored at the tip by default and can be walked back to genesis.
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 dense sentences with the return semantics front-loaded and the parameter behavior following. No filler, no redundant restatement of the tool name, and the default/range facts are placed where they are needed.
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?
For a two-parameter, zero-required, read-only query with an annotation-rich safety profile, the description covers what is returned and how the window is anchored. The only gap is response shape — what a 'competing orphan' entry looks like — which matters since there is no output schema, but it is a minor omission.
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 coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining the directional semantics of 'to' (lowering it browses older history, floor at genesis) rather than merely restating its type and default; the limit range, however, is just repeated from the schema.
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 first sentence names the resource and scope precisely: canonical chain blocks plus competing orphan blocks within a height window. That distinguishes it from get_block (single block) and recent_orphans (no height window), though it never states a verb or explicitly names 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?
It gives real operational guidance — omit 'to' for the tip, lower it to walk back toward genesis — which effectively describes how to page through history. It does not say when to prefer this over recent_orphans, reorgs, or get_block, so the agent must infer tool selection from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How mining-pool attribution was established over a window: share proven by view key, claimed by pool API, inferred from coinbase, or unattributed. window in 1h,6h,24h,48h,7d.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Time window, one of 1h, 6h, 24h, 48h, 7d. Example: 24h | 24h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, open-world query. The description adds useful context about the attribution categories being reported, but it does not describe return structure, aggregation behavior, or data freshness beyond what the annotations provide.
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?
The definition is short and front-loads the core concept, with no filler. The second sentence duplicates the schema's window enum, which is mildly redundant, but overall it remains efficient and easy to parse.
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?
For a simple one-parameter read-only tool, the description gives enough context about what attribution categories will be reported and what windows are valid. It does not explain the exact output shape, but the tool's complexity is low and the annotations cover the safety profile.
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 single window parameter has 100% schema description coverage, including its allowed values and default. The description repeats the accepted window values but adds no additional meaning beyond the schema, so the baseline 3 is appropriate.
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 clearly states the resource: mining-pool attribution provenance broken down into proven, claimed, inferred, or unattributed shares over a window. It is specific enough to distinguish this from pool distribution data, though it does not explicitly name or contrast sibling tools.
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 explicit when-to-use or when-not-to-use guidance, and no alternative tools such as pool_distribution or pool_sources are referenced. An agent can infer that this is for attribution-confidence analysis, but the description leaves selection entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one block by its 64-character block hash: height, previous hash, size, difficulty, reward, coinbase, transaction list and merge-mining tags.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | 64-character hexadecimal hash. Example: 418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds value by enumerating the payload contents (transaction list, merge-mining tags), which hints at a potentially large response, but it says nothing about error behavior for missing hashes or how reorged/orphaned blocks are handled.
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?
One sentence, front-loaded with the purpose and followed by an itemized field list. Every clause carries information and nothing is padded.
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?
With no output schema, the description appropriately compensates by enumerating the returned fields, which is the key missing structured information. The remaining gap is edge-case behavior (invalid length, unknown hash, stale blocks) on a tool flagged openWorld.
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 coverage is 100%: the single hash parameter already carries a format note and a worked example. The description restates '64-character block hash' without adding syntax, normalization, or acceptance of height/prefix forms, so it does not meaningfully exceed the schema.
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 verb phrase ('Full detail for one block') plus the lookup key (64-character block hash), so the agent knows exactly what comes back. It never names the sibling search_block, which is the likely alternative for finding a block without a hash, so the differentiation is only implicit.
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?
Usage is implied rather than stated: the requirement of a 64-character hash signals 'use this when you already have the hash.' There is no explicit when-not or pointer to search_block for discovery-by-height/time, and no mention of behavior for unknown or orphaned hashes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The live Haveno XMR/USD order book, both sides, priced against centralized spot.
Each price level carries its cumulative depth, offer count, payment methods and a
reversible flag. asks are makers selling XMR, so taking one means buying; bids
are makers buying, so taking one means selling. Offers are advertisements with
differing payment methods rather than a matched book, so nothing executes on its own
and the best bid can sit at or above the best ask.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: offers are advertisements rather than a matched book, nothing self-executes, and the best bid can sit at or above the best ask. That last point is valuable anti-misinterpretation context, though it stops short of describing pagination, depth limits, or staleness of the 'live' data.
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?
Front-loaded with what the tool returns, then the field inventory, then the crucial caveat about unmatched advertisements. Every sentence carries information; nothing is padded or repeated from the annotations.
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?
With no input parameters and no output schema, the description must carry the return-shape burden and does: it enumerates cumulative depth, offer count, payment methods, and the reversible flag per price level. Combined with the crossed-book caveat, an agent has enough to call it and interpret results 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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The description correctly spends no space on argument semantics.
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 the specific resource (the live Haveno XMR/USD order book), its scope (both sides), and its pricing basis (centralized spot). Explicitly defines what `asks` and `bids` mean in maker terms, which lets an agent distinguish this from siblings like haveno_premium or haveno_payment_methods without opening a schema.
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?
Usage is implied (fetch this when you need current order-book depth), but the description never states when to call this versus haveno_premium or haveno_payment_methods. It also doesn't say whether the book is a snapshot or streaming, leaving an agent to infer freshness from 'live'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executed Haveno trades grouped by payment method, with the premium over spot.
window in 30d,90d,180d,1y,all. currency in USD,EUR. The premium tracks how reversible and convenient the payment rail is, not privacy: every one of these trades is equally non-KYC. The reversible flag is our own classification, not a Haveno field.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Time window, one of 30d, 90d, 180d, 1y, all. Example: 180d | 180d |
| currency | No | Fiat currency of the trades, USD or EUR. Example: USD | USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description usefully discloses that the 'reversible' flag is a derived classification rather than a Haveno field and that results are aggregated per payment method, but it omits whether small-sample methods are filtered or what the aggregation period grain is.
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?
The purpose is front-loaded and the interpretive note is valuable, but enumerating window and currency values duplicates the schema verbatim and the mid-sentence line break makes the text read awkwardly. Some sentences could be trimmed without loss.
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?
With no output schema and a derived-analytics tool, the description supplies the essential context an agent needs: what the premium represents and that reversibility is a local classification. Only the shape of the returned rows (per-method fields, sample sizes) is left unexplained, which is a modest gap.
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 coverage is 100% and both parameters are described with defaults and examples, so the schema does the heavy lifting. The description merely restates the allowed values ('30d,90d,180d,1y,all' and 'USD,EUR') without adding meaning, keeping this at the baseline.
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 opens with a specific verb-and-resource statement: executed Haveno trades grouped by payment method with the premium over spot. It is clearly distinct from haveno_book (order book) and haveno_premium (presumably aggregate premium), though it never names those siblings explicitly.
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 guidance on when to choose this over haveno_premium or haveno_book, nor any stated exclusions or preconditions. The interpretive notes (premium reflects rail reversibility, not privacy) help read the output but do not route an agent between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a transaction by its 64-character hash: whether it is in the mempool or mined, its block, confirmations, whether it is spendable yet, the pool that mined its block, and whether that height was ever contested by a reorg. No amounts, senders or recipients: the protocol encrypts them.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | 64-character hexadecimal hash. Example: 418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the bar is lower; the description still adds real value by listing exactly what is observable (mempool vs mined, block, confirmations, spendability, mining pool, reorg contention) and by disclosing the hard limitation that amounts and parties are encrypted. That limitation is the key behavioral fact an agent could otherwise mis-assume, though nothing is said about not-found or unconfirmed-input handling.
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?
Front-loaded with verb plus resource, followed by a single dense enumeration of return facets and one short clarifying sentence about encrypted data. The list is long but every item is distinct and informative; nothing is filler.
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?
With no output schema, the description carries the burden of describing returns and does so thoroughly across status, block, confirmations, spendability, pool and reorg history, plus the privacy caveat. Minor gaps remain around unknown-hash behavior and whether results are cached or point-in-time.
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 coverage is 100% and the schema already gives the 64-character hex format with a worked example, so the description's "64-character hash" phrasing is largely redundant. No additional meaning (e.g., prefix matching, case sensitivity) is contributed beyond the schema.
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 verb and resource ("look up a transaction by its 64-character hash") and immediately enumerates the returned facets, which cleanly separates it from block-oriented siblings like get_block and search_block. An agent can tell what this tool answers without opening the schema.
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 lookup key (tx hash) and the questions it answers make the appropriate use case clear, and the explicit statement that amounts/senders/recipients are unavailable steers the agent away from using it for value-transfer questions. It does not, however, name a sibling alternative or state a when-not condition in tool-selection terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block-time variance time series (seconds between blocks). 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 | 24h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds that results are a time series in seconds, which is useful. It says nothing about aggregation granularity, series length, or response shape, but that is a modest gap for a simple read.
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, front-loaded sentences with no filler. The enum restatement duplicates the schema, which is a minor redundancy but keeps the description self-contained.
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?
For a single optional parameter read tool with full schema coverage and complete annotations, little explanation is required. However, with no output schema, the description is the only source for what the series actually contains (per-block samples vs. aggregated variance), and it leaves that unresolved.
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 window enum is documented in the schema with an example, so the description's repetition of '1h,24h,7d,30d,90d,1y,5y' adds no new meaning. The only added semantics is that the window scopes the emitted time series. Baseline 3 applies when the schema does the heavy lifting.
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 metric and unit: 'Block-time variance time series (seconds between blocks)'. An agent can tell this apart from network_hashrate or network_emission, though it never explicitly names which sibling to prefer. The phrase 'variance time series' is slightly ambiguous about whether values are block times or statistical variance.
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 mention of alternatives among the many network_* siblings, and no preconditions. Usage is only inferrable from the metric name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
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.
Network hashrate time series. 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that: no units (hashes/second vs. EH/s), no resolution or sampling granularity within a window, no data freshness or source, and no indication of how much history is returned.
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 fragments, front-loaded with the resource identity before the parameter note. The second fragment is pure duplication of the schema enum, which is wasted space, but the overall text is tight and imposes no reading burden.
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?
For a single optional-parameter, read-only tool with full schema coverage and annotations, the definition is minimally sufficient to call correctly. It is still missing interpretation-critical context such as hashrate units and the sampling resolution inside each window, which an agent would need to present results meaningfully.
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 documents the window parameter with its default and full enum list. The description merely repeats the same value list verbatim, adding no syntax, format, or edge-case meaning (e.g. whether an unsupported value errors or falls back to the default). Baseline 3 is appropriate when the schema does all the work.
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?
"Network hashrate time series" names the specific resource and the shape of the return (a series), which distinguishes it from siblings such as network_blocktime, network_emission, and network_info. It stops short of an explicit verb (e.g. "get"/"returns") and never explicitly contrasts itself with those siblings, so it is clear but not maximally differentiated.
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 prerequisites, and no mention of any alternative tool. The agent must infer from the name alone that this is the tool for historical hashrate rather than block time or emission; nothing in the text routes it or excludes other choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Monero network state: latest indexed height, difficulty, network hashrate and mempool size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds that the values reflect 'current' network state and lists the four fields, but says nothing about freshness/lag, units, or whether mempool size is transaction count or bytes.
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?
A single front-loaded sentence with the resource stated first and the returned metrics enumerated after the colon. No filler, no redundancy, and the most important information leads.
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?
With no output schema, the description carries the burden of describing return values and does so by naming all four metrics. The remaining gap is that units and formats (e.g., hashrate denomination, whether height reflects indexer lag) are unspecified, which matters for a metrics tool with no structured output definition.
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 tool takes zero parameters, so there is no parameter meaning to convey; the baseline for a no-argument tool applies. The description correctly signals a parameterless snapshot call, leaving nothing for the schema to contradict.
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 (Monero network state) and enumerates the metrics returned: indexed height, difficulty, hashrate, and mempool size. It does not, however, distinguish itself from siblings like network_hashrate, network_mempool, or network_blocktime, which cover overlapping data, so an agent cannot tell purely from the text whether to use this aggregate tool or the narrower ones.
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 explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The only implicit signal is the word 'Current', suggesting a live snapshot rather than historical analysis, but an agent must infer that this is the aggregate entry point versus the per-metric tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mempool size time series (number of pending transactions). 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 | 24h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the semantic of what is measured (pending transaction count over a window), which is useful given there is no output schema. It does not add anything else about behavior, which is acceptable here.
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 with the resource and metric front-loaded; nothing is padded. The second sentence largely duplicates the schema's window enum, which is minor but not harmful.
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?
For a one-parameter read tool whose annotations cover safety, the definition is close to sufficient. However, with no output schema, it does not describe the shape of the series (resolution, number of points, aggregation method), which an agent might need to interpret results.
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 single 'window' parameter already documents the allowed values and an example. The description restates the same enumeration, adding no default value, format, or interpretation detail beyond the schema, so 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 states a specific resource and metric: a mempool-size time series counting pending transactions. That clearly distinguishes it from siblings like network_hashrate, network_blocktime, or pool_distribution. It lacks an explicit verb (e.g. 'returns'/'fetches') but the intent is unambiguous.
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 guidance on when to use this tool versus an alternative, and no prerequisites or exclusions are mentioned. The only usable context is the metric name itself, which happens to be unique among the listed siblings, so usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mining-pool distribution over a window: block share per pool, largest-pool share and the Nakamoto coefficient (minimum pools controlling >50% of blocks). window in 1h,6h,24h,48h,7d.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Time window, one of 1h, 6h, 24h, 48h, 7d. Example: 24h | 24h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotent, non-destructive, openWorld), so the description's real contribution is disclosing the shape of the result set: three distinct derived metrics and the >50% threshold used for the Nakamoto coefficient. That matters because no output schema exists. It stops short of saying whether shares are percentages or fractions, or how pools with zero blocks are represented.
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?
One dense sentence that front-loads the computation and closes with the window values; nothing is extraneous. It is slightly telegraphic, but every clause carries information.
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?
For a single optional parameter, read-only analytics tool with no output schema, the description adequately covers what is computed and what the returned fields mean. Minor gaps remain around output units and the sibling distinction, but nothing an agent needs in order to call it is missing.
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 coverage is 100% and the single 'window' parameter already carries its enum list and default, so the description restating '1h,6h,24h,48h,7d' adds nothing new. Baseline 3 applies when the schema does the heavy lifting.
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 analytic resource ('Mining-pool distribution') and the exact quantities computed: block share per pool, largest-pool share, and the Nakamoto coefficient, which it defines inline. It does not distinguish itself from the sibling pool_sources, so an agent must guess which of the two to pick for pool-related questions.
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 metric definitions imply the analytical use case, but there is no explicit when-to-use statement, no exclusions, and no pointer to pool_sources as the alternative for source/registry data. The guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reachability status of each mining-pool API used for block attribution.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so safety is covered. However, the description does not disclose the behavior that matters most for this tool: whether it performs live network probes against each pool API (with possible latency/timeouts) or reads a cached status, nor how often status refreshes. Nothing contradicts the annotations, but the description adds little beyond them.
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?
A single clause, front-loaded on the exact resource being reported, with no filler or redundancy. It is efficient, though its terseness leaves the action implied rather than stated.
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?
With no output schema and no parameters, the description carries the full burden of explaining what the agent receives, yet it never says what a 'reachability status' looks like—per-pool entries, up/down flags, timestamps, error reasons—nor whether results are live or cached. For a zero-argument, zero-output-schema tool, this is a substantive gap.
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 tool takes zero parameters and schema coverage is 100%, so there is no parameter semantics to explain. Baseline 4 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—the reachability status of each mining-pool API used for block attribution—which clearly separates it from siblings like pool_distribution (block share by pool) or chain_provenance. It is a noun phrase without a verb, so the agent must infer that calling it returns status data, but the subject matter is unambiguous.
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 stated prerequisites, and no mention of alternatives or exclusions. An agent cannot tell from the description whether this is for diagnosing attribution gaps, monitoring upstream health, or pre-checking before pool_distribution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Monero (XMR) price: centralized spot plus both sides of the Haveno peer-to-peer book.
Returns the best offer and the amount-weighted average on each side, resting depth, offer counts, and round_trip_cost_pct: the cost of buying XMR and selling it straight back, which is far larger than the headline premium.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds valuable context beyond that by explaining what the return contains and why round_trip_cost_pct matters, noting it is far larger than the headline premium. It does not mention freshness, caching, or rate limits, but the key behavioral nuance is covered.
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?
The description is front-loaded with the core purpose and then efficiently lists what is returned and explains the key derived metric. Every sentence adds value, with no redundant or filler wording.
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?
For a parameterless, read-only pricing tool with no output schema, the description is largely complete: it says what is combined, what metrics are returned, and why one metric matters. It could be slightly stronger by noting data freshness or update cadence, but the essential context is present.
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 tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter detail because none exist, and instead focuses on output semantics.
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 clearly states it returns the current Monero price, combining centralized spot with both sides of the Haveno P2P book, and lists specific derived metrics like best offer and round_trip_cost_pct. This scope differentiates it from raw book or premium tools, though it does not explicitly name sibling alternatives.
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?
Usage is implied: call this when you need a current XMR price including P2P execution costs. However, there is no explicit guidance on when to use this versus haveno_book, haveno_premium, or network_info, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most recent orphan blocks with their canonical counterpart at the same height, newest first. limit 1..50; window in 24h,48h,7d,30d,90d,180d,1y,all (default all, so the last N orphans are returned however old they are).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of orphans to return, 1 to 50. Example: 20 | |
| window | No | Time window, one of 24h, 48h, 7d, 30d, 90d, 180d, 1y, all. Example: 7d | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds beyond that: result ordering (newest first), the fact that each row is paired with its canonical block at the same height, and the important interaction between window and limit. It does not mention result caps or payload shape, but the added behavioral context is solid.
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 what the tool returns and in what order, then the parameter constraints. No filler and no repetition of the schema's example values.
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?
With only two optional parameters, existing annotations and no output schema, the description covers the essentials: what is returned, ordering, and both parameter semantics. Only a hint at the shape of the canonical-counterpart fields would make it fully self-sufficient.
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 coverage is 100%, so the baseline would be 3, but the description adds real meaning: the limit range 1..50 and, crucially, that 'all' means the last N orphans regardless of age rather than an unbounded set. That interpretation of the default is not obvious from the schema alone.
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 (orphan blocks), a specific pairing (each with its canonical counterpart at the same height) and an ordering (newest first). It is clearly distinct from get_block or search_block, though it never explicitly contrasts itself with close siblings like reorgs or reorg_stats.
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?
It explains the default window semantics ('all', so the last N orphans are returned however old they are), which is genuinely useful context for choosing arguments. However, it never says when to prefer this tool over reorgs, chain_fork_window or get_block, so the when-to-use decision against siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detected Monero chain reorganizations, most recent first, with fork point, depth and affected transactions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the ordering guarantee and the shape of each record, which is useful. However, it says nothing about result volume, pagination, or what an empty result means (no reorgs vs. failure), and with no output schema these behavioral details are not documented elsewhere.
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?
A single sentence with no wasted words, front-loaded with what is returned and followed by the ordering and per-record fields. Refreshingly compact for a zero-argument tool.
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?
For a simple zero-param read tool the description covers the essentials, but because there is no output schema, the description is the only specification of return shape and it lists only three fields without types or whether the list is bounded. It also omits what happens on an empty result, leaving a modest gap relative to the missing output contract.
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 parameters, the schema baseline is a 4, and nothing in the description conflicts with that. The description also clarifies the response items (fork point, depth, affected transactions), which is a mild but positive addition beyond the empty schema.
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 gives a specific resource (Monero chain reorganizations) and states exactly what each entry carries: fork point, depth and affected transactions. It is clear what the tool returns, but it does not distinguish itself from the similar siblings reorg_stats, recent_orphans and chain_fork_window.
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 explicit guidance on when to use this versus reorg_stats (counts/metrics) or recent_orphans, which a similar tool server offers. The ordering hint ('most recent first') is the only usage-adjacent detail, and the choice between this and its closest sibling is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate reorg statistics over windows: counts, average and maximum depth, affected transactions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds the return payload shape (counts, average and maximum depth, affected transaction count), which matters because there is no output schema, but it leaves 'over windows' undefined — no default range, granularity, or pagination behavior.
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?
A single front-loaded sentence with concrete metrics and no filler; every clause carries information. It is slightly under-specified rather than verbose — the 'over windows' qualifier is the one fragment that does not resolve to anything concrete.
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?
For a zero-argument aggregation tool with no output schema, the description usefully lists the metrics returned and carries the read-only safety profile via annotations. It is still incomplete on the two things an agent needs: what 'windows' means (time range, bucket size) and how this differs from the sibling 'reorgs' tool.
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 tool takes zero parameters, so the baseline is 4; the schema needs no textual compensation. The phrase 'over windows' hints at a windowing concept that has no corresponding input, a minor ambiguity, but nothing is left undocumented.
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 uses a specific verb ('Aggregate') plus resource ('reorg statistics') and enumerates the reported metrics (counts, average/max depth, affected transactions), so an agent can tell what it produces. It never distinguishes itself from nearby siblings like reorgs, recent_orphans, or chain_fork_window, so it falls short of a 5.
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 explicit when-to-use guidance, no prerequisites, and no named alternative. With siblings such as 'reorgs' (likely the raw list) and 'recent_orphans' present, the agent must guess whether this is the summary view or a duplicate, which is exactly the ambiguity usage guidance should resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a block by height (a number) or by 64-character hash, anywhere in the chain down to the genesis block (height 0). Returns the block detail plus whether it is canonical or an orphan.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Block height as a number, or a 64-character hex block hash. Example: 3000000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real value by disclosing the return content (block detail plus canonical vs orphan status), but says nothing about not-found behavior, chain context, or response size for what is an open-world lookup.
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 with zero waste: the lookup modes and scope come first, the return value second. Nothing is repeated from the schema verbatim beyond the necessary format constraint.
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?
For a one-parameter read-only lookup with no output schema, the description covers input forms, scope, and the salient return signal. What is missing is error/not-found behavior and any hint of what 'block detail' contains, which is minor given the tool's simplicity.
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 coverage is 100% and the single parameter already documents the number-or-64-char-hex format. The description only reinforces the length and adds the valid height range (0 to chain tip), so the baseline of 3 applies with minimal added meaning.
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 verb (Find) and resource (block), and specifies the two accepted query forms and the full chain scope down to genesis. It does not, however, distinguish itself from the sibling get_block, so an agent cannot tell from this text alone why both exist.
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?
Usage is only implied: 'anywhere in the chain down to the genesis block' plus the canonical/orphan return value hints this is for arbitrary or potentially non-canonical block lookups. There is no explicit when-to-use statement and no exclusion pointing at get_block, recent_orphans, or chain_provenance for the adjacent cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
chain_fork_window2 fields changedInput schema / properties / limit / descriptionAdded value: +"Number of heights in the window, 10 to 500. Example: 100"Input schema / properties / to / descriptionAdded value: +"Highest block height of the window; omit for the current tip. Example: 3000000"chain_provenance1 field changedInput schema / properties / window / descriptionAdded value: +"Time window, one of 1h, 6h, 24h, 48h, 7d. Example: 24h"get_block1 field changedInput schema / properties / hash / descriptionAdded value: +"64-character hexadecimal hash. Example: 418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"haveno_payment_methods2 fields changedInput schema / properties / currency / descriptionAdded value: +"Fiat currency of the trades, USD or EUR. Example: USD"Input schema / properties / window / descriptionAdded value: +"Time window, one of 30d, 90d, 180d, 1y, all. Example: 180d"haveno_premium1 field changedInput schema / properties / window / descriptionAdded value: +"Time window, one of 24h, 7d, 30d, 90d, 1y. Example: 7d"lookup_transaction1 field changedInput schema / properties / tx_hash / descriptionAdded value: +"64-character hexadecimal hash. Example: 418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"network_blocktime1 field changedInput schema / properties / window / descriptionAdded value: +"Time window, one of 1h, 24h, 7d, 30d, 90d, 1y, 5y. Example: 30d"network_emission1 field changedInput schema / properties / window / descriptionAdded value: +"Time window, one of 1h, 24h, 7d, 30d, 90d, 1y, 5y. Example: 30d"network_hashrate1 field changedInput schema / properties / window / descriptionAdded value: +"Time window, one of 1h, 24h, 7d, 30d, 90d, 1y, 5y. Example: 30d"network_mempool1 field changedInput schema / properties / window / descriptionAdded value: +"Time window, one of 1h, 24h, 7d, 30d, 90d, 1y, 5y. Example: 30d"pool_distribution1 field changedInput schema / properties / window / descriptionAdded value: +"Time window, one of 1h, 6h, 24h, 48h, 7d. Example: 24h"recent_orphans2 fields changedInput schema / properties / limit / descriptionAdded value: +"Number of orphans to return, 1 to 50. Example: 20"Input schema / properties / window / descriptionAdded value: +"Time window, one of 24h, 48h, 7d, 30d, 90d, 180d, 1y, all. Example: 7d"search_block1 field changedInput schema / properties / query / descriptionAdded value: +"Block height as a number, or a 64-character hex block hash. Example: 3000000"lookup_transactionrecent_orphans1 field changedInput schema / properties / windowAdded value: +{
+ "default": "all",
+ "title": "Window",
+ "type": "string"
+}haveno_bookhaveno_payment_methodshaveno_premiumchain_fork_windowchain_provenanceget_blocknetwork_blocktimenetwork_emissionnetwork_hashratenetwork_infonetwork_mempoolpool_distributionpool_sourcespricerecent_orphansreorg_statsreorgssearch_blockLive crypto order book heatmap PNG, CVD, imbalance and liquidations from 4 public exchange feeds.
Live crypto market data: prices, funding, OI, liquidations, regimes, GEX, whales, sentiment, macro.
Live order flow for Bitcoin, gold, US 500, oil and more: order book walls, liquidity and funding.
Live crypto data: why a coin or the market is moving (funding, OI, positioning, flow).
Add one secure layer between your agents and this server.