Verified XRP Ledger answers with proof: payment, send, and issuer checks. Pay per call via x402.
Scored across 14 tools
Most tools target a distinct XRP Ledger concern (pre-send, payment verification, watching, issuer identity, token identity, network health, images), and descriptions explicitly separate close pairs like free_send_check vs send_check and issuer_check vs token_check. The free/paid split of the same send check is the main source of potential confusion, but the boundary is spelled out clearly.
All names use lowercase snake_case, which is consistent and readable. However the conventions mix verb_noun (get_sample, list_services, learn_about_bruk) with noun_noun (issuer_check, payment_check, token_check) and noun-only (large_payments, receipt_card), so it is not a single predictable pattern.
14 tools is well within a reasonable range and each maps to a real service. A few are meta/onboarding helpers (get_sample, list_services, learn_about_bruk, token_types) rather than live checks, so the count is slightly padded but not excessive.
The surface covers the core XRP Ledger verification lifecycle: pre-send checks, post-send verification, payment watching, issuer and token identity, network health, and proof images. Gaps are minor (e.g. no general account/tx history read or trust-line setup), and mostly outside the stated verification purpose.
Free, one per user per day. Before sending XRP or a token on the XRP Ledger: will the payment fail (missing destination tag, unfunded or deleted account, no trust line, wrong issuer) and what should you double-check? Returns the verdict, blockers, and cautions from a validated ledger. The paid send_check adds the full evidence and has no daily limit.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | ||
| issuer | No | XRP Ledger r-address | |
| source | No | XRP Ledger r-address | |
| network | No | Default mainnet | |
| currency | No | ||
| destination | Yes | XRP Ledger r-address | |
| destination_tag | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds the cost model, the one-per-day rate limit, and that results come from a validated ledger (data-freshness context). It does not describe latency, pagination, or what happens when the daily quota is exhausted, but the rate/cost disclosure is the valuable part beyond annotations.
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-loads the cost/quota constraint, then the use case, then the return shape, then the paid alternative — a logical order with no filler sentences. The parenthetical failure list is dense but each item is load-bearing; slight compression loss is acceptable.
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?
No output schema exists, but the description states the return contents (verdict, blockers, cautions) and their source (validated ledger), plus the quota and the paid upgrade path. For a 7-param, single-required-param check tool this is enough for an agent to call it and interpret the result.
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 57% schema description coverage across 7 params, the description compensates by tying failure modes to specific inputs: destination_tag (missing tag), destination (unfunded/deleted account), currency+issuer (no trust line, wrong issuer). It says nothing about source, network, or amount semantics, so the coverage gap is only partly closed.
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 and resource ('check before sending XRP or a token on the XRP Ledger') and enumerates the failure classes it detects (missing destination tag, unfunded/deleted account, no trust line, wrong issuer). It also explicitly distinguishes itself from the sibling send_check, 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?
Gives an explicit precondition ('Before sending XRP or a token'), a constraint ('Free, one per user per day'), and names the alternative with the condition that selects it ('The paid send_check adds the full evidence and has no daily limit'). When-to-use and when-to-escalate are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Returns a recent real answer from a Brük service (cached up to 5 minutes) so you can see the format before paying.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely new behavioral context: the call is free and results are cached up to 5 minutes, so the agent knows the answer may be stale. It doesn't disclose rate limits or whether sampling a service incurs any cost later.
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 the key fact ('Free.'), and every clause adds information: free, real answer, cache window, and preview purpose. Nothing is wasted.
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 does tell the agent it will receive a real sample answer, which sets expectations for format preview. It remains incomplete on the service enum semantics and on whether the sample is a truncated or full response.
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 0% and the single 'service' parameter carries a six-value enum, yet the description only says 'from a Brük service' without explaining what pulse, payment-check, issuer-check, token-check, large-payments, or send-check mean. With zero schema documentation, the description fails to compensate for the coverage gap.
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 and resource: it returns a recent real answer from a Brük service as a free sample. That distinguishes it from the paid, service-specific siblings like send_check and token_check, though it never names those alternatives 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?
The phrase 'so you can see the format before paying' implies the usage condition: preview the response shape before invoking a paid service. However, no alternatives are named, no when-not-to-use guidance is given, and nothing says whether multiple services can be sampled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether an XRP Ledger token issuer is who it claims to be: two-way domain verification (on-ledger Domain field against the domain's xrp-ledger.toml), tokens issued and outstanding, and control flags such as freeze, clawback, blackholed, and multisign. Useful before accepting or holding a token. The first call each day returns the real answer without payment. After that, about $0.01 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| account | Yes | XRP Ledger r-address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only/open-world, but the description adds substantial context beyond them: the daily free-call rule, the payment rail (x402, USDC on Base, or XRP/RLUSD), billing on the first call for a payment watch, and that bad input or ledger outages are never charged. This is exactly the kind of operational detail an agent cannot derive from structured fields.
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?
Purpose and scope are front-loaded in the first long sentence, followed by when-to-use and pricing. Every sentence carries distinct, non-redundant information with 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?
For a one-parameter read tool with no output schema, the description covers what is checked and the billing model, which is sufficient to call it correctly. It does not describe the shape of the returned verdict (booleans vs. flags), a minor 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?
Single parameter with 100% schema description coverage, so the schema already documents the r-address fully. The description adds no syntax or format guidance beyond it, making the baseline 3 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 and resource ('Checks whether an XRP Ledger token issuer is who it claims to be') and enumerates the exact checks performed: two-way domain verification, tokens issued/outstanding, and control flags. This is unmistakably distinct from siblings like token_check or payment_check.
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?
Gives a clear use context ('Useful before accepting or holding a token') plus the cost/prerequisite model (first call per day free, then ~$0.01 via x402). No alternatives or exclusions are named, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists large XRP Ledger payments (50,000+ XRP or major stablecoins) in a recent window of up to 120 minutes, each independently re-checked on the ledger, with an explicit note when the window is not fully covered. Useful for market and liquidity monitoring. The first call each day returns the real answer without payment. After that, about $0.02 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| minutes | No | ||
| min_value | No | At least 50000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint, the description discloses genuine behavioral traits: each payment is 'independently re-checked on the ledger', an 'explicit note' is emitted when the window is not fully covered, and it spells out billing edge cases ('Bad input and ledger outages are never charged') and the free-first-call-per-day rule. These are exactly the non-obvious traits an agent needs and cannot get from annotations.
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?
What the tool does is front-loaded in the first sentence, and the remaining sentences each carry distinct weight (coverage caveat, use case, pricing, error policy). It runs slightly long with pricing detail, but no sentence is pure 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 still conveys coverage behavior, cost model, and failure handling, which is substantial for a billing-sensitive tool. The main residual gap is the return shape (what a 'payment' record contains) and the role of the limit parameter, though both are minor given the free/simple listing nature.
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 only 33% (only min_value carries a description, and even that is just 'At least 50000'). The description compensates partially by tying the 120-minute maximum to 'up to 120 minutes' and the threshold to '50,000+ XRP', but it says nothing about what limit does or how to choose it, leaving one of three parameters undocumented in both places.
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 and resource ('Lists large XRP Ledger payments') plus a concrete threshold (50,000+ XRP or major stablecoins) and window cap (up to 120 minutes), so the agent knows the scope precisely. It does not name or rule out any sibling (e.g., payment_check, payment_watch), so differentiation is left 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?
'Useful for market and liquidity monitoring' implies a use context but gives no when-not guidance and never points to an alternative sibling. The pricing rules ('first call each day ... free', 'A payment watch is paid from the first call') hint at cost trade-offs but do not explicitly route an agent between this tool, payment_check, or payment_watch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Brük's site, its short film about the XRP Ledger (chapters, transcript, captions), and the credit line for quoting it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint=true already declares a safe read. The description adds that the content is free and details the film's chapters, transcript, captions, and credit line—useful context about what the tool surfaces beyond the annotation's safety profile.
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?
Single sentence with a leading 'Free.' fragment; it is brief and front-loads the content list. No redundancy, though the fragment could be integrated more smoothly.
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-param, read-only informational tool with no output schema, the description specifies exactly what information is provided (site, film, chapters, transcript, captions, credit line), which is sufficient for an agent to know what to expect.
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?
Zero parameters, so baseline 4 applies. The description does not need to document any parameters, and the empty schema is self-explanatory.
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 the resource (Brük's site and short film) and the specific content included (chapters, transcript, captions, credit line), which differentiates it from the payment/ledger siblings. However, it lacks a clear verb like 'get' and opens with the fragment 'Free.', slightly reducing clarity.
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 explicit when-to-use guidance or alternatives; usage is only implied by the name 'learn_about_bruk' and the informational nature. Siblings are unrelated, so inference is easy, but the description adds nothing to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ledger moment image (1200x675 PNG): one validated XRP Ledger ledger drawn as one tile per transaction in ledger order, colored by type (payments, DEX offers, trust lines, AMM, NFTs, other), failed transactions hollow, with counts, fees burned, XRP supply, and the ledger hash. Latest validated ledger by default. Useful for posts, reports, and newsletters about network activity. The first call each day returns the real answer without payment. After that, about $0.02 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Default mainnet | |
| ledger_index | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnly/openWorld; the description goes well beyond them by disclosing the pricing model (first call per day free, ~$0.02 via x402 USDC on Base or XRP/RLUSD on XRPL), that payment watches are charged from the first call, and that bad input or ledger outages are never charged. Those billing and failure-path traits are exactly what an agent needs before invoking a metered tool.
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 resource and its visual semantics, then defaults, then cost. The payment sentences are long but each carries decision-relevant information (free tier, price, non-billable failures); only the 'posts, reports, newsletters' clause is close to 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 correctly specifies the return artifact and its contents, plus defaults and cost. The main remaining gap is the network parameter's effect and whether historical ledger_index values are accepted/validated, but nothing essential to calling it correctly 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 50% and only the network enum is documented in-schema. The description compensates partly by defining the default ledger_index behavior ('Latest validated ledger by default'), though it says nothing about how network=testnet affects the rendered ledger.
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 artifact (1200x675 PNG of one validated XRP Ledger ledger) and exactly what it depicts: one tile per transaction in ledger order, colored by type, failed transactions hollow. This is distinguishable from sibling tools like ledger_pulse or large_payments without opening any 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 defaults (latest validated ledger) and an audience ('posts, reports, and newsletters about network activity'), which implies usage, but never states when to choose this over siblings such as ledger_pulse or receipt_card, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
XRP Ledger network health right now: latest validated ledger, close time, transactions and payments in it, fee levels, load, and rolling averages cross-checked against a direct ledger read. Useful before submitting XRP Ledger transactions or when reporting current network conditions. The first call each day returns the real answer without payment. After that, about $0.001 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only and open-world nature. The description adds important behavioral detail beyond annotations: first call each day is free, thereafter about $0.001 via x402 (USDC on Base or XRP/RLUSD on XRPL), payment watch is paid from the first call, and bad input or ledger outages are never charged.
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-loads the tool's purpose and returned data, then moves to usage context and payment terms. Every sentence contributes useful information, and there is no redundant 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 enumerates what the tool returns and explains pricing, exceptions, and usage context. For a zero-parameter read-only endpoint, this is complete enough for an agent to call it 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 and the schema is empty with 100% coverage. There is no parameter meaning to add, so the baseline score of 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?
Clearly states the resource and scope: XRP Ledger network health right now, and enumerates the returned data including latest validated ledger, close time, transactions, fees, load, and rolling averages. It does not explicitly differentiate itself from sibling tools such as ledger_moment, so it is strong but not fully sibling-routing.
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 clear usage context: useful before submitting XRP Ledger transactions or when reporting current network conditions. It lacks explicit when-not-to-use guidance or direct alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Lists every Brük service with price, inputs, and its HTTP endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful context beyond that: the call is 'Free' (no billing/auth cost implied) and it discloses the shape of what comes back (price, inputs, endpoint) — valuable since there is no output schema.
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 waste, front-loaded with the most decision-relevant fact ('Free') followed by scope and payload. Every clause earns its place.
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 catalog listing with no output schema, the description covers purpose, cost, and roughly what is returned. It could note ordering/pagination or whether results are cached, but nothing critical for correct invocation 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?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.
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 and resource ('Lists every Brük service') plus the fields returned (price, inputs, HTTP endpoint). This is clearly distinguishable from the sibling tools, which are all specific checks/samples, but it does not explicitly name an alternative it could be confused with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no alternatives named. The only usage signal is the implied 'browse the catalog' context, which the agent must infer from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies that an XRP Ledger payment settled as expected: validation, result code, destination, destination tag, currency, issuer, and the amount actually delivered, which exposes partial-payment tricks. Useful when confirming that a customer or counterparty really paid. The first call each day returns the real answer without payment. After that, about $0.01 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| tx | Yes | 64-character transaction hash | |
| amount | No | ||
| issuer | No | XRP Ledger r-address | |
| network | No | Default mainnet | |
| currency | No | ||
| destination | No | XRP Ledger r-address | |
| destination_tag | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint; the description adds substantial behavior the annotations cannot: an x402 charge model (~$0.01 USDC on Base / XRP / RLUSD on XRP Ledger), a free first call per day, the fact a payment watch is billed from its first call, and that bad input and ledger outages are never charged. Cost and billing-failure semantics are exactly what an agent needs before invoking a paid tool.
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?
Purpose is front-loaded in the first sentence, followed by the use case and then the billing caveats. The pricing paragraph packs four clauses, but each carries decision-relevant information (free first call, price, charging exclusions), so little is wasted.
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 compensates by enumerating what is verified/returned (validation, result code, destination, destination tag, currency, issuer, delivered amount) plus the cost and error-charging rules. For a 7-parameter paid read tool with 57% schema coverage, nothing essential to calling it correctly 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 only 57% and two parameters (amount, currency, destination_tag) have no schema description, but the description supplies their meaning: they are expected values the tool checks against the delivered payment, with amount explicitly tied to detecting partial-payment tricks. The network parameter and the required/optional split are still left to the schema, keeping this below a 5.
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?
Specific verb + resource + enumerated verification scope ('validates that an XRP Ledger payment settled as expected: validation, result code, destination, destination tag, currency, issuer, and the amount actually delivered'). It also names the failure mode it defends against (partial-payment tricks), which distinguishes it from siblings like payment_watch or token_check without needing to open 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?
Gives a clear use context: 'Useful when confirming that a customer or counterparty really paid.' It also implies a division of labour with payment_watch via the pricing note ('a payment watch is paid from the first call'), so a day's first check is a cheap way to confirm a single payment. It stops short of an explicit when-not/alternative statement (e.g. 'for ongoing monitoring use payment_watch').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Payment arrival alert: watches an XRP Ledger address for up to 24 hours and POSTs a signed webhook when a matching payment is final (validated, tesSUCCESS, delivered amount checked), or a watch.expired event if none arrives. Payments that land during restarts are still caught. Useful when waiting on an incoming payment without polling. The first call each day returns the real answer without payment. After that, about $0.05 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| issuer | No | XRP Ledger r-address | |
| address | Yes | XRP Ledger r-address | |
| network | No | Default mainnet | |
| webhook | Yes | Public https URL for signed events | |
| currency | No | ||
| min_amount | No | ||
| destination_tag | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing the exact success criteria (validated, tesSUCCESS, delivered amount checked), the watch.expired outcome, restart resilience, and the x402 charging model including what is never charged. This is exactly the behavioral context a paid, open-world watcher needs.
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?
Purpose is front-loaded and the pricing sentences earn their place for a metered tool. It is slightly dense (mixing event semantics, resilience, and billing in one paragraph) but has 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?
For a tool with no output schema but an implicit return contract, the description covers the outcomes an agent must anticipate (final payment event vs. watch.expired) and billing behavior. It stops short of describing the immediate call response or how the webhook payload is structured.
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 8 parameters and only 50% schema description coverage, several params (currency, min_amount, destination_tag, hours) are undocumented in both schema and description. The description implies matching-payment semantics ('delivered amount checked') but does not map meaning to specific parameters, so it neither compensates for the gap nor falls below 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?
States a specific verb+resource+scope: watches an XRP Ledger address for up to 24 hours and POSTs a signed webhook on a matching final payment. It distinguishes itself from polling-style siblings like payment_check by framing the asynchronous alert model.
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 says it is 'useful when waiting on an incoming payment without polling', giving a clear use context, and adds detailed pricing/charge conditions. It does not explicitly name an alternative sibling tool to use instead, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verified payment receipt image (1200x675 PNG) for an XRP Ledger payment, drawn only from the validated ledger: delivered amount, sender, recipient, destination tag, ledger, close time, result, optional expectation checks, and a QR code to the public explorer. Only final outcomes are drawn; not-found or unvalidated transactions are not charged. Useful for showing a person proof that a payment arrived. The first call each day returns the real answer without payment. After that, about $0.02 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| tx | Yes | 64-character transaction hash | |
| amount | No | ||
| issuer | No | XRP Ledger r-address | |
| network | No | Default mainnet | |
| currency | No | ||
| destination | No | XRP Ledger r-address | |
| destination_tag | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only readOnly/openWorld, but the description adds the charging contract that actually governs agent behavior: only final outcomes are billed, not-found/unvalidated transactions are not charged, bad input and ledger outages are free, and a payment watch is billed from the first call. It also discloses the data provenance (validated ledger only) and the output artifact, which annotations cannot express.
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-loads what the tool returns before the pricing and charging rules, and the dense sentences each carry distinct information. It runs long for a tool description, but no sentence is pure filler given the payment model it must explain.
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 correctly compensates by enumerating the receipt contents, image dimensions, and explorer QR code. Combined with the charge policy, an agent has what it needs to call and interpret results; only the semantics of the optional expectation-check parameters remain under-explained.
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 7 parameters and only 57% schema description coverage, the description is the only place some semantics could be filled in, and it largely is not. It gestures at the optional filters via "optional expectation checks" and echoes destination tag/ledger/result, but never explains how amount, issuer, currency, destination, or destination_tag constrain matching against the transaction. Baseline 3 for partial coverage with marginal 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?
States a concrete verb and artifact: it produces a verified payment receipt image (1200x675 PNG) for an XRP Ledger payment, and enumerates the fields rendered into it. That distinguishes it from read-only siblings like payment_check or ledger_moment by output format and use case, though it never names an alternative directly.
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?
Gives a clear triggering context ("Useful for showing a person proof that a payment arrived") and pricing conditions that affect when to call (first call each day free, ~$0.02 after). It does not name sibling alternatives or explicitly say when NOT to use it versus a plain payment check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-send check for an XRP Ledger payment: whether the destination is activated, requires a destination tag, blocks or pre-approves senders, can hold the token (trust line, or MPT opt-in and issuer approval), is blackholed, and whether the source can afford it. For a multi-purpose token, pass mpt_issuance_id instead of currency and issuer. Returns ok_to_send, send_with_caution, or will_fail with reasons. Useful before any irreversible XRP Ledger payment. The first call each day returns the real answer without payment. After that, about $0.005 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | ||
| issuer | No | XRP Ledger r-address | |
| source | No | XRP Ledger r-address | |
| network | No | Default mainnet | |
| currency | No | ||
| destination | Yes | XRP Ledger r-address | |
| destination_tag | No | ||
| mpt_issuance_id | No | 48-hex MPT issuance id. Use instead of currency and issuer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint and openWorldHint; the description adds substantial context beyond them: the three possible verdicts, the x402 cost model (~$0.005, USDC on Base or XRP/RLUSD), the free first call each day, that a payment watch is billed from the first call, and that bad input and ledger outages are never charged. This is exactly the kind of billing/eligibility behavior an agent must know before invoking.
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 check list is front-loaded, then return values, then cost, then billing exceptions - a logical order with no filler sentences. It is on the long side and the pricing detail is split across three sentences that could be tightened, but every element is decision-relevant.
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 full burden of explaining returns and it does so ('Returns ok_to_send, send_with_caution, or will_fail with reasons'). Combined with the enumerated pre-checks, billing rules, and the MPT parameter rule, an agent has everything needed to call and interpret this 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 coverage is only 63%, so the description must compensate, and it does for the trickiest case: 'For a multi-purpose token, pass mpt_issuance_id instead of currency and issuer' documents a cross-parameter exclusivity rule the schema does not state. The destination-tag concept is also surfaced via the check list. Amount, source, network, and currency formats remain unexplained, keeping this below a 5.
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 ('Pre-send check for an XRP Ledger payment') and enumerates exactly what is verified (activation, destination tag, sender blocking, trust line/MPT approval, blackhole, affordability). That is far more specific than a bare title. It does not, however, differentiate itself from the sibling free_send_check or payment_check, so an agent cannot tell from the description alone which of those to prefer.
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?
'Useful before any irreversible XRP Ledger payment' gives a clear usage context and the pricing paragraphs implicitly bound when the call is worthwhile. There are no explicit exclusions and no named alternatives, notably the sibling free_send_check, which is a directly competing option an agent would want compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identifies one XRP Ledger token from the validated ledger: a trust-line token (currency code plus issuer) or a multi-purpose token (48-hex issuance id). Reports the type, issuer domain check, supply, and controls that can freeze, lock, claw back, or restrict holders. Issuer-written metadata is quoted and is not treated as fact; a missing asset class is reported missing. Does not check other chains, and does not rate legal backing or solvency. Useful before accepting an MPT or any other token. The first call each day returns the real answer without payment. After that, about $0.01 via x402 (USDC on Base, or XRP / RLUSD on the XRP Ledger). A payment watch is paid from the first call. Bad input and ledger outages are never charged.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer | No | XRP Ledger r-address | |
| currency | No | Trust-line token code, with issuer. Not XRP. | |
| mpt_issuance_id | No | 48-hex multi-purpose token issuance id. Use this or currency plus issuer, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint/openWorldHint, but the description adds substantial undisclosed behavior: the x402 payment model (first call per day free, ~$0.01 after, USDC/XRP/RLUSD), that payment watches are billed from the first call, and that bad input and outages are never charged. It also warns that issuer-written metadata is quoted rather than asserted as fact and that missing asset classes are reported as missing.
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?
Purpose and scope are front-loaded in the first two sentences, followed by exclusions and then billing terms; every sentence carries information an agent needs. The pricing sentences are slightly repetitive (free first call, paid watch, no charge on failure) and could be tightened without meaning to earn a 5.
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 three-optional-parameter, read-only, no-output-schema lookup, the description covers what is returned, what is deliberately not covered, the disclosure stance on issuer metadata, and the cost model. Nothing an agent needs to decide to call it or to interpret the result 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% and the schema already states the currency-needs-issuer rule and the "use this or currency plus issuer, not both" exclusivity for mpt_issuance_id. The description restates the same parameter relationships without adding format or edge-case detail 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?
States a specific verb+resource: identify one XRP Ledger token, distinguishing the two supported forms (trust-line via currency+issuer, MPT via 48-hex issuance id). It also enumerates exactly what is reported (type, issuer domain check, supply, freeze/lock/clawback/restriction controls), which cleanly separates it from siblings like issuer_check or token_types.
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?
"Useful before accepting an MPT or any other token" gives clear when-to-use context, and it explicitly excludes other chains, legal backing, and solvency. It stops short of naming sibling alternatives (issuer_check, token_types) for the cases it does not cover, so routing is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free guide, not a live check. Which XRP Ledger token types Brük can identify, how to pass an MPT issuance id, and which other chains Brük does not read.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by framing the tool as a static 'free guide' rather than a live query. It also discloses a scope boundary (which chains Brük does not read), which is genuinely useful behavioral context beyond the annotation.
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 that leads with the most decision-relevant fact ('Free guide, not a live check') and then lists coverage. 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?
For a zero-parameter, read-only reference tool with no output schema, the description adequately conveys what content the guide contains. Naming the specific alternative live-check tool would make it fully 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?
The tool takes zero parameters, so the baseline is 4. The mention of 'how to pass an MPT issuance id' is guidance about another flow rather than a parameter of this tool, but it is informative and not misleading.
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 (XRP Ledger token types Brük can identify) and enumerates the guide's coverage: token types, how to pass an MPT issuance id, and unsupported chains. It also distinguishes itself from the live-check siblings by declaring 'not a live check,' though it never names token_check directly.
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?
'Free guide, not a live check' gives a clear condition for selection: use this for reference rather than for validating a specific token. The alternative (a live check such as token_check) is implied but not named, so the routing is clear without being fully explicit.
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.
get_sample1 field changedInput schema / properties / service / enumPrevious value: -[
- "pulse",
- "payment-check",
- "issuer-check",
- "large-payments",
- "send-check"
-]New value: +[
+ "pulse",
+ "payment-check",
+ "issuer-check",
+ "token-check",
+ "large-payments",
+ "send-check"
+]send_check1 field changedInput schema / properties / mpt_issuance_idAdded value: +{
+ "description": "48-hex MPT issuance id. Use instead of currency and issuer.",
+ "type": "string"
+}token_checktoken_typesfree_send_checkledger_momentreceipt_cardget_sampleissuer_checklarge_paymentslearn_about_brukledger_pulselist_servicespayment_checkpayment_watchsend_checkXRPL token rug-checks, issuer reputation & AMM data for AI agents. Pay-per-call USDC via x402.
Verify XRP payments on Flare FDC. Agents subscribe or pay per attestation via x402 on XRPL.
XRP research, paper arena and free XRPL transaction explanations / x402 diagnostics. No signing.
Read-only XRP Ledger token-risk, issuer-authenticity and wallet-security checks.
Add one secure layer between your agents and this server.
