xmr.pub MCP — Monero node, fees, mempool & payment verification (read-only)

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only oracle and even explains the Monero adaptive-block consensus model, which adds useful domain context, but it never states caching behavior, rate limits, data freshness, or explicitly that it is a safe non-mutating 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?

A single compact sentence front-loads the tool's purpose (fee tiers + block weight stats) and appends useful explanatory context about adaptive blocks. No filler, though the trailing consensus explanation is slightly tangential to invocation.

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 correctly compensates by enumerating what is returned (current fee tiers, block weight median and limit). For a zero-parameter read oracle this is largely complete, with only behavioral details like caching/freshness left unstated.

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; baseline for a parameterless tool is 4. The schema is an empty object with additionalProperties false, consistent with the description.

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 dynamic block size / fee rate) and states exactly what it returns: current fee tiers, plus median and limit block weight. It is clear what the tool does, though it does not explicitly distinguish itself from the overlapping sibling xmr_mempool_health.

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 statement of when to call this tool versus alternatives such as xmr_mempool_health, nor any prerequisites. Usage (fee estimation / block-size inspection) can only be inferred from the tool's name and topic.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose the composition of the returned metrics (including the anti-double-spend key-image tracking), which is useful behavioral context given there is no output schema. However, it never states that this is a read-only/side-effect-free call, nor whether it hits a local or remote node, so key behavioral guarantees remain unstated.

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 dense sentence that front-loads the resource (mempool health) and then lists the concrete metrics. No filler, no 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?

For a no-argument read tool with no output schema, the description adequately tells the agent what data comes back (tx count, size, median fee, oldest wait, key-image scale). It omits only operational context such as data source/auth and whether values are point-in-time snapshots.

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 per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side.

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 (mempool) and enumerates the concrete metrics returned: queued tx count, size, median fee rate, oldest-tx wait time, and key-image tracking scale. This distinguishes it from generic siblings like xmr_node_status, though it never explicitly contrasts itself with them.

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?

No indication of when to prefer this tool over xmr_node_status or xmr_fee_oracle, no prerequisites, and no exclusions. The agent must infer that 'mempool health' is relevant when congestion/fee conditions matter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does disclose the paid access model (x402 credit pack or API key) and the read-only nature of the view key, plus what the response contains. It stops short of stating rate limits, privacy implications of submitting a view key, or latency, so it is strong but not exhaustive.

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 the purpose label and output summary, then inputs, then when/do-not-use, then pricing. Dense but structured, with only minor redundancy (the period_days 1–30 range repeats the schema).

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 annotations, the description usefully enumerates the returned aggregates and the access model, covering most of what an agent needs. Minor gaps remain around pagination/limit interaction and rate/credit consumption.

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 schema already documents all five parameters. The description restates address/view_key/period_days and its 1–30 range but adds no syntax or semantic detail beyond the schema; 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?

States a specific verb+resource (aggregate an address's payment history over a time window) and enumerates the exact aggregates returned (daily counts/amounts, totals, confirmations, pending, common-amount distribution). It also names the sibling it is not for (xmr_verify_payment), so an agent can route without opening either 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?

Provides an explicit 'When to use' list (financial reconciliation, monthly flow, tax records, anomalous-amount investigation) and an explicit 'Do not use' with the named alternative for single-payment confirmation. Both positive and negative routing are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses that data comes from the node's on-chain network scope and that access is paid via x402 credit pack or API key. It does not state whether estimation is deterministic, latency, or rate limits, leaving a small gap.

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?

Three compact sentences: calculation, when to use, when not to use. Front-loaded with the core operation, though the mixed-language formatting is slightly less scannable than plain English.

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 an estimation tool with no output schema, the description names all return values (daily/monthly gross/net, break-even price, payback days), which is exactly the needed context. It omits precision or currency handling caveats, but is largely complete.

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 parameters are already documented in the schema; the description adds no syntax or format details beyond what the schema provides. Baseline 3 is appropriate 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?

The description states a specific calculation with named outputs: daily/monthly gross and net earnings, break-even electricity price, and payback days, from given hashrate and power/cost. It is a forward-looking estimator, clearly distinguishable from sibling tools like xmr_fee_oracle or xmr_verify_payment.

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?

Explicitly gives when to use (deciding whether to mine, which machine to buy, acceptable electricity price) and when not to use (querying historical earnings, since this is an estimate not a settlement). This direct routing is rare and valuable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does disclose a meaningful trait: the data comes from xmr.pub's self-hosted full node, which tells the agent about the source and trust boundary, and 'real-time' signals freshness. It says nothing about caching intervals, failure modes when the node is unreachable, or rate limits.

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 compact sentence, front-loaded with the resource ('Monero mainnet real-time status') and followed by a colon-delimited list of metrics, then a short provenance note. No filler; the only mild redundancy is listing fields that overlap with sibling tools.

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 and no parameters, so the description is the only place return content can be conveyed — and it does enumerate the returned metrics, which is exactly what the agent needs. It falls short of 5 only because it omits error behavior and any indication of how the response is structured or how fresh the snapshot is guaranteed to be.

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. There are no inputs whose semantics could be clarified, and the description correctly focuses on what the call returns instead.

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 scope: real-time Monero mainnet status, then enumerates the exact dimensions returned (height, sync state, difficulty/hashrate, mempool, chain DB size). That is far more than a restatement of the name. It only partially differentiates from the sibling xmr_mempool_health, since mempool is listed here as one of several metrics.

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 by the word 'status' and the live-metric enumeration — an agent can infer this is a general node-health snapshot. However, there is no explicit when-to-use guidance and no routing against the overlapping siblings xmr_mempool_health or xmr_fee_oracle, which also surface network-level data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does meaningful work: it discloses the server-side mechanism (one-time read-only wallet decryption), the safety property of view_key (read-only, cannot transfer funds), the returned fields (paid / confirmations / difference), and the access model ('Paid: x402 credit pack or API key'). It stops short of failure modes, rate limits, or what happens with a mismatched tx_key, so it is strong but not complete.

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 a bracketed category tag, then the mechanism, then clearly labelled When to use / Do not use / Paid blocks. The bilingual phrasing is dense but every clause carries routing or behavioral information; nothing is padding.

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 an 8-parameter, no-annotation tool with no output schema, the description still covers inputs, mechanism, return semantics (paid/confirmations/difference), batch limit context, and cost/auth. Nothing an agent needs in order to decide to call it and construct a valid request 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 description coverage is 100%, so the baseline would be 3; the description goes beyond the schema by explaining why tx_key is required (it is the payer-side key the server needs to decrypt the amount) and reiterating that view_key is read-only. It does not explain amount_tolerance_percent despite the schema's thin 'default 1.0' note, which caps this at 4.

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?

States a specific verb+resource (核验门罗到账 / verify Monero payments) with scope markers (one or many, batch-capable) and enumerates the exact inputs it consumes. It explicitly distinguishes itself from the sibling xmr_verify_tx_proof by naming it in the 'Do not use' clause, so an agent can route correctly without opening either 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?

Provides explicit when-to-use scenarios (order arrival confirmation, OTC receipt verification, batch reconciliation) and an explicit do-not-use case with the alternative tool named. The only remaining decision — single vs batch — is covered by the description plus the payments array.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does useful work: it discloses that the server verifies with a one-time read-only wallet, persists nothing, logs nothing, and cannot transfer funds. It omits error/failure behavior and rate limits, but the safety profile is genuinely additive.

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?

It is a single front-loaded paragraph that opens with a bracketed tag and the core action, then lists the inputs and safety note. Slightly dense, but every clause carries information and there is no 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?

There is no output schema, so the description should cover what a successful or failed verification returns, and it does not — the return shape and failure cases are left unspecified. Inputs and behavioral safety are covered, but the missing result semantics leave a real gap for a cryptographic verification 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?

Schema description coverage is 100% and the schema already explains txid, address, tx_key (from payer) and view_key (read-only, non-spendable). The description only restates the same four inputs, adding no syntax or format meaning 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 states a specific verb+resource: verify that a transaction really paid to your address using a tx-proof. It is clear and concrete, but it never distinguishes itself from the sibling xmr_verify_payment, which sounds like the same job.

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 implies the scenario (zero-private-key reconciliation when a counterparty gives you a tx_key) and names the required inputs, but it gives no explicit when-to-use/when-not guidance and never routes the agent between this tool and xmr_verify_payment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.