@xrpl-utilities/mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.184
Disambiguation4/5
Tools are grouped by clear domain prefixes (pulse, trust, vault, sentinel, telemetry, flows, desk) which helps distinguish purposes. Some overlap exists within pulse analytics (e.g., exchange_flow_delta vs exchange_net_flow vs entity_positioning) and between ripple_topology and cex_attribution, but descriptions are specific enough to guide selection.
Naming Consistency3/5
The pattern is mostly xrpl_<domain>_<descriptor>, but the descriptor varies between noun phrases (e.g., recent_events, network_stats) and verb-led names (list_domains, get_domain, scan). 'scan' appears in three different domains with different meanings (vault_scan, sentinel_scan, flows_scan). While the domain prefix provides predictability, the mixed style prevents a higher score.
Tool Count2/5
41 tools is a heavy load for a single server, exceeding the typical comfortable range. Even with domain organization, the sheer number increases cognitive load and reduces discoverability. Splitting into separate servers per domain (pulse, trust, flows, etc.) would improve scoping.
Completeness4/5
The server provides broad coverage across XRPL analytics: market events, whale activity, trust domains, RWA vaults, wallet classification, ETF flows, settlement volumes, and macro telemetry. Paid tool flows are properly chained (get_quote → get_status → get_results). Minor gaps include no direct account balance/transaction query and no generic token metadata tool beyond token_health, but these do not significantly hinder the stated utility.
Average 3.8/5 across 41 of 41 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 3 community issues answered or closed in the last 6 months
- 92 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the data is anonymized and that wallet addresses are not exposed, which is useful privacy context. However, it does not state whether the operation is read-only, mention any rate limits or data freshness, or describe the output format beyond distributions. This leaves significant behavioral gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but awkwardly structured with a sentence fragment ('Free.'). It front-loads cost rather than core purpose, and uses unexplained jargon ('relay-burst detector'). While it is not verbose, the structure could be improved for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should explain the return shape and usage context. It only says the tool provides 'distributions' but does not specify the data structure, pagination (despite a limit param), or how to interpret the findings. The description is inadequate for an agent to fully understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (limit) with 0% description coverage, and the description does not mention the limit parameter at all. The description fails to explain how to use the parameter or what it controls, leaving the agent to infer from the parameter name and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing anonymized Ripple-counterparty auto-discovery and relay-burst detector findings, with score-tier and funding-source distributions. This distinguishes it from sibling tools like xrpl_pulse_ripple_topology or xrpl_pulse_cex_attribution, though it lacks an explicit action verb like 'returns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 tool versus alternatives. The description does not mention any exclusions or alternative tool recommendations. The only contextual hint is 'Free' which might imply cost comparison, but it does not help with selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a limitation ('specific addresses not exposed') and mentions cost ('Free'), but does not state whether the operation is read-only, or describe error behavior or response structure. For a data tool, the lack of permission/safety disclosure leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff, though the initial 'Free.' is an unnecessary prefix. The semicolon-separated list of output fields is compact and front-loaded. Overall, it is concise but could be structured slightly better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description adequately conveys the output fields and addresses privacy limitations. However, it does not explain how the 'limit' parameter affects results or what the response object looks like. Given the absence of an output schema, this leaves moderate ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('limit') with 0% description coverage, and the description does not mention it. The parameter's purpose as a result-count limiter is left to inference from its name and constraints. The description adds no meaning beyond the schema's min/max/default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource ('CEX attribution walker findings') and the method ('backward-walked payment chains ending at named exchanges'), distinguishing it from sibling exchange-flow tools. The noun phrase 'findings' is less direct than a verb, but the resource and scope are clear. The list of returned fields adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative tools are mentioned. The 'CEX attribution' focus implies usage for tracing payments to exchanges, but exclusions are not stated. Sibling tools like exchange-flow-delta are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It reveals that the endpoint is free, returns a paginated index, and includes a specific field set—useful context that suggests a read-only operation. However, it does not explicitly state that there are no side effects, lacks rate-limit or quota info, and does not clarify behavior of the status filter beyond what the schema already lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a fragment, with unnecessary words stripped. It front-loads the important 'Free' and immediately communicates scope and return fields. Every part contributes value, and there is no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and no annotations, the description is moderately complete: it discloses pagination, free access, and the fields returned. However, it omits when-to-use guidance, explanation of the status parameter's effect, and any note about ordering or defaults. Given the lack of structured annotations, the description could do more to fully inform an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only status has an explicit description). The description itself does not explain limit, offset, or status, merely mentioning 'Paginated' which weakly implies limit/offset. Since coverage is low, the description needed to compensate but did not add meaning beyond the schema's constraints and the status enum string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is an index of all PermissionedDomain operators, enumerates the returned fields (address, label, jurisdiction, status, domain count, issuer count), and distinguishes it from sibling tools like xrpl_trust_list_domains (which lists domains) and xrpl_trust_operator_drilldown (which drills down into one operator). However, it uses 'Index of' rather than an explicit verb like 'List' or 'Get', making the action slightly nominalized.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The only hints are 'Free' and 'Paginated', which imply general browsing but do not indicate situations where a sibling tool like xrpl_trust_operator_drilldown or xrpl_trust_list_domains would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral context. It discloses the $0.10 cost, which is a key behavioral trait, but it does not state whether the scan is read-only, describe output size or limits, or mention any prerequisites. The term 'deep dive' hints at extensive data but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and manages to convey cost, purpose, and input flexibility. It is front-loaded with the cost warning and uses compact phrasing. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool without an output schema, the description lists key data categories but omits any information about the response format, date ranges, or pagination. Given the large set of sibling tools, the description does not clarify how this differs from related tools like xrpl_vault_daily_flow or xrpl_pulse_rwa_summary. This makes it insufficient for a fully informed selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for both parameters, with 100% coverage. The description's mention of accepting wallet address, issuer label, or currency code repeats the schema's issuer description without adding new meaning. Thus the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a per-issuer RWA deep dive and enumerates specific data points (supply, mint/burn, AMM exposure, daily history). It accepts issuer identifiers in multiple forms, which distinguishes it from sibling summary tools like xrpl_pulse_rwa_summary. However, it lacks a direct action verb, relying on the tool name 'scan' for the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a detailed per-issuer analysis is needed, but it does not explicitly contrast with sibling tools or state when not to use it. The paid cost is a consideration but not a usage guideline. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is free and returns counts, but does not explicitly say it is read-only, mention data coverage, rate limits, or any authentication requirements. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences. It front-loads the cost ('Free') and then gives a clear purpose. Every word contributes to understanding, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately conveys the core output (counts per country). It could clarify what 'unattributed bucket' means, but the overall picture is complete enough for a simple rollup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making parameter semantics irrelevant. The baseline score of 4 applies because there is nothing for the description to explain about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a jurisdiction rollup, specifying per-country operator and issuer counts with an unattributed bucket. It distinguishes itself from sibling tools by focusing on geographic distribution, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer usage solely from the name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only adds 'Free' and lists output categories; it does not state that this is a read-only operation, describe any access requirements, rate limits, or potential side effects. This is minimal coverage for a tool that offers no other structured behavioral hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the key selling point ('Free') and then efficiently enumerates the exact metrics computed. There is no redundant phrasing or unnecessary explanation; every word contributes to understanding the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the main purpose and return categories reasonably well. However, it does not clarify how the window is applied, what the output format looks like, or whether there are any caveats about data freshness or computation limits. It is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter, window_days, as 'Trailing days' with clear defaults and bounds (100% schema coverage). The description's 'configurable window' adds no new semantic detail beyond what the schema provides, so it stays at the baseline for fully covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this tool provides an aggregate of PermissionedDomain activity across the ecosystem, listing specific metrics (domain count, operator count, credential and market event totals). This scope differentiates it from per-domain sibling tools like xrpl_trust_list_domains or operator_drilldown, though it lacks an explicit verb like 'get' or 'summarize'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Ecosystem-wide aggregate' implies use for high-level overviews versus detailed per-domain queries, but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. The intended use case is only implied, not stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does add some context: it states the tool is free, uses UTC-day granularity, and includes specific volume components. However, it doesn't explicitly disclose read-only behavior, response format, freshness, or historical coverage, leaving gaps for a data-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler, conveying the data content and a use-case reference efficiently. The leading 'Free.' is a minor structural oddity as it starts the description with a pricing note rather than the core action, but it does not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description lists the returned data components and time granularity, which is helpful. Yet it does not explicitly state the response structure (e.g., an array of objects with dates and those fields) or date anchoring, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since the only parameter 'days' is fully described with type, default, min, and max. The description adds only the UTC-day temporal context and does not elaborate on how 'days' behaves beyond what the schema already states, so it adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a per-UTC-day series of XRPL exchange flow with four explicit components (inbound, outbound, net, settlement volume), making the resource and content specific. However, it lacks an explicit verb like 'get' or 'retrieve', and it doesn't contrast with the similar sibling xrpl_pulse_exchange_net_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Same series used in XR-Flows ETF correlation' implies a use case for ETF correlation, but no explicit when-to-use or alternative comparison is provided. It does not state when to choose this over sibling tools like xrpl_pulse_exchange_net_flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the critical sign convention (positive = off-exchange accumulation, negative = distribution), which is a significant behavioral trait. It also mentions the data source ('labeled whale events') and includes a cost indicator ('Free'). However, it does not discuss rate limits, required authentication, or error scenarios, and with no annotations the description carries full responsibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, opening with 'Free' and 'Per-exchange directional net flow'. It conveys the core functionality and the unique sign interpretation in just two sentences without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema, no annotations), the description covers the key aspects: data source, scope, output fields (inflow/outflow/net, trend, market positioning flag), and sign interpretation. Minor gaps remain around the exact meaning of 'trend' and 'market positioning flag', but the description is sufficiently complete for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'hours' is already fully described in the schema (default 24, max 336), and the description text adds no additional parameter semantics. With 100% schema coverage, the baseline of 3 is appropriate; the description does not compensate with anything extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: per-exchange directional net flow from labeled whale events, with a holder-centric sign convention. While it doesn't explicitly name sibling tools as alternatives, the phrasing 'per-exchange' and 'net flow' distinguishes it from broader flow tools sufficiently to infer its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like exchange_flow_delta or whale_flow_24h. There is no mention of use cases, exclusions, or preference conditions. The only hint is 'Free', which does not direct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only notes 'Free' and describes the output sections, but does not reveal whether the data is static, cached, or real-time, nor any side effects or required permissions. The agent gains little insight into the tool's operational behavior beyond its output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core identity ('Ripple ecosystem topology map') and uses a structured colon-delimited list to detail the three output categories. Every phrase adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description offers a high-level summary of what to expect (Source, Pipeline, Exits) but leaves ambiguity around the exact structure, 'curated middle layer by role' is vague, and no mention of data freshness or size. It is adequate for an initial understanding but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for 0 params is 4, and the description does not need to explain parameter meaning. It correctly omits any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'Ripple ecosystem topology map' and enumerates its three components (Source, Pipeline, Exits). It is distinct from sibling tools which focus on events, flows, or telemetry. However, it lacks an explicit verb like 'get' or 'list', making it more of a noun phrase than an action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would call this when it needs an ecosystem-wide topology overview. However, there is no explicit guidance on when to prefer this over sibling tools like network_stats or entity_positioning, nor any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the cost ($0.10 USD) and the data fields returned, adding useful context beyond the schema. However, it does not explicitly state side-effect safety, authentication requirements, or rate limits. With no annotations available, the description carries a heavier burden but covers only some behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the cost and then summarizes the output fields. Every word contributes value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the cost and the specific output fields, giving a reasonable understanding of the result. It could be more explicit about the return shape (list vs. single object) and any failure modes, but it is largely complete for an initial assessment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for 'payment_signature' ('x402 payment header'), and the description's mention of 'Paid ($0.10 USD)' reinforces the parameter's purpose. No additional syntax or behavioral semantics are added 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('credential issuers across PermissionedDomains') and specifies the exact output fields (address, label, referencing domain count, credential types issued). It lacks an explicit verb like 'list' or 'get,' but the intent is unambiguous and it distinguishes itself from sibling tools focused on domains, operators, and events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as xrpl_trust_list_domains or xrpl_trust_get_domain. The description only states what the tool returns, not the intended use case or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly notes 'Free' and lists the data contents, which adds some context. However, it does not state whether the operation is read-only, whether it has side effects, or any rate limits or data source specifics, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence, front-loaded with 'Free.' and then a compact list of the summary contents. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description lists the key output components sufficiently. It could add a bit more context (e.g., what 'RWA' means or the exact time range for the 24h flow), but as a zero-arg summary rollup, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. The baseline for 0 params is 4, and the description does not need to add parameter details. It correctly focuses on the output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates a cross-issuer RWA rollup with a specific list of metrics (obligations, net-circulating supply, trustline count, 24h mint/burn flow, AMM pool exposure). Although it lacks an explicit verb, 'rollup' conveys an aggregated summary, and the focus on RWA distinguishes it from siblings like network stats or token health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It only states what the tool provides, without any 'use this for...' or 'if you need X, use Y' context, leaving the agent to infer that this is the RWA-specific summary tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cost ($0.10 USD) and the one-shot nature, which are useful behavioral traits. However, it does not describe the payment/result flow (e.g., whether results are returned synchronously or via get_results), potential side effects, or data freshness. More transparency would be needed for full clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the critical cost and one-shot nature, then efficiently lists the snapshot contents. Every word contributes value, with no redundancy or filler. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the components of the snapshot but does not specify the output format, structure, or how this tool relates to sibling telemetry tools like get_results and get_quote. Given the absence of an output schema and the complexity of the macro snapshot, the description is incomplete for an agent to fully anticipate the result or the payment workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with a description ('x402 payment header'), yielding 100% coverage. The tool description adds no additional parameter semantics. The baseline is 3 due to schema coverage, but the description does not clarify why the parameter is not required in the schema despite being a paid tool, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a paid, one-shot XRPL macro snapshot and lists the specific content areas (supply breakdown, liquidity flows, AMM state, Active Float model, utility floor price). This distinguishes it from sibling telemetry tools like xrpl_telemetry_get_status or xrpl_telemetry_get_quote by emphasizing a single, comprehensive snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It mentions 'Paid' and 'One-shot' but does not state scenarios where this is preferred over sibling tools like xrpl_telemetry_settlement_totals or xrpl_telemetry_dex_pair_volume, nor does it exclude any use cases or provide workflow context (e.g., whether to call get_quote first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently states the cost ($0.10 USD) and lists the types of information returned. However, it does not mention whether the operation is read-only, how payment is processed, or what the response format looks like, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately highlights the paid nature and cost, then succinctly enumerates the scope. Every word earns its place with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain return behavior and any prerequisites more thoroughly. It lists content categories and cost but does not clarify the payment workflow (payment_signature is not required in the schema), error conditions, or why the tool is worth using versus other operator tools. It is adequate but leaves important gaps for an agent to act confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters already described in the input schema. The description adds the cost context for payment_signature but does not directly explain the parameters beyond what the schema already provides. It does not compensate for or extend parameter semantics significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'deep dive' on one PermissionedDomain operator, listing specific content areas (domains, credentials, jurisdiction, DID identity, institutional issuers, lifecycle events). This distinguishes it from sibling tools like xrpl_trust_operator_attribution by emphasizing depth, though the verb 'deep dive' is less direct than 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when an agent needs comprehensive detail on a single operator, but it does not explicitly state when to use it over alternatives or mention any exclusions. Sibling tools such as xrpl_trust_list_operators_index and xrpl_trust_operator_attribution exist, but no comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It does disclose that the stream is cursor-paginated and free, adding useful behavioral context. However, it omits details such as default time range, ordering, whether events are real-time, or any rate limits, and it does not describe the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus a fragment. It front-loads the key differentiator (XLS lifecycle events) and includes only essential details (pagination, cost). There is no wasted wording, making it highly skimmable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple event stream with three optional parameters and no output schema, the description gives a reasonable overview by listing event types and mentioning pagination. However, it lacks return format examples and default time-window behavior, and it does not explain how the lifecycle event types map to the `tx_type` filter. Given the read-only nature, this is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 67% of parameters with descriptions, including 'since' as an event-id cursor and 'tx_type' as a transaction type filter. The description's mention of 'cursor-paginated' loosely relates to the `since` and `limit` parameters but adds no concrete parameter semantics. For a moderately covered schema, the description does not need to compensate heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an XLS-70/80/81 lifecycle event stream, enumerating specific event categories (domain creates/deletes, credential activity, permissioned offers, AMM events). This distinguishes it from sibling tools like xrpl_trust_list_domains. However, it lacks an explicit verb like 'list' or 'get', relying on the noun phrase 'event stream' to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as xrpl_pulse_recent_events or xrpl_trust_list_domains. It implies usage for trust lifecycle event monitoring but does not state when not to use it or mention alternative tools. The 'Free' qualifier offers minimal contextual signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is free and describes the daily data frequency and rolling window calculation, which adds useful behavioral context. However, it does not mention side effects, return format, or data limitations beyond the causation caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with 'Free,' and contains no redundant words. Every phrase adds detail: scope, method, and a clarifying caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately explains what it computes. However, it does not explicitly state what the return value looks like (e.g., a series of correlation coefficients), which could be a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'days' parameter with a clear description ('Trailing days'), and the tool description adds no additional parameter semantics. Baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a daily correlation between ETF AUM and XRPL exchange-flow delta across tracked funds, with a 7-day rolling Pearson correlation. The phrase 'Correlation only, not causation' adds specificity and distinguishes it from sibling tools like xrpl_flows_etf_flow_summary and xrpl_flows_exchange_flow_delta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The 'Correlation only, not causation' caveat is a methodological note, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the transparency burden. It discloses the $0.10 cost, newest-first ordering, and the heterogeneous event types, which are important behavioral traits. It does not explain payment mechanics (how payment_signature is used), rate limits, or confirm read-only status, leaving some ambiguity for a paid HTTP-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, leading with the cost, then the core purpose, then content and filters. Every phrase earns its place, and the description is front-loaded with the most decision-relevant fact (the $0.10 charge). No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only-looking paid feed with 6 parameters and no output schema, the description covers the essentials: cost, content scope, ordering, and filters. However, it omits pagination behavior (despite before_iso implying backward pagination) and does not hint at response shape. This is adequate for a simple recent-events tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), but the description adds meaning by mapping the 'kind' filter to the listed event categories (news, whale activity, lifecycle, Sentinel, RWA), clarifying the enum values. It also links 'min whale USD' to the filter and groups since_iso/before_iso as 'time range', which the schema already details. This adds value without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a feed of recent XRPL signal events with a mixed content scope (news, whale activity, lifecycle, Sentinel, RWA). It lacks an explicit verb like 'list' but 'most-recent ... events' plus 'filterable' effectively conveys retrieval. It distinguishes from siblings by emphasizing the broad mixed feed and newest-first ordering, though it doesn't name a specific alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a broad, mixed feed of recent XRPL events and highlights filterability by kind, time range, and whale USD. The upfront cost note is useful usage context. However, it offers no explicit when-to-use vs. sibling tools or exclusions, so agents must infer suitability from the content mix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully adds 'Newest first, UTC-aligned' and 'Free', but does not mention read-only status, pagination, or error behavior. It provides some context but is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'Free' and the core purpose. Every clause adds value: granularity, metrics, ordering, timezone, and intended use. No redundant language or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for a simple, two-parameter data retrieval tool, including the data points returned (USD totals, payment counts, XRP drops, RLUSD) and ordering. The absence of an output schema is partially compensated by these details. It does not explain the exact return structure, but that is not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'count' and 'bucket' having meaningful descriptions. The description's mention of 'daily / weekly / monthly' and 'per bucket' adds minimal extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a bucketed time-series of XRPL settlement volume, specifying granularities and included metrics. It lacks an explicit verb like 'fetch' or 'return', but the noun phrase is unambiguous and distinct from sibling tools such as settlement_totals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'For charting or change-point detection,' which gives a clear use case. However, it does not explicitly mention alternatives or when not to use this tool, relying on the sibling tool names to imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cost ($0.10 USD) and event categories, which is useful. However, it omits critical behavioral details such as whether payment_signature is required, how pagination works, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the cost and then states the purpose. It is compact and without waste, though it could have been more structurally complete with an explicit verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid tool with 4 parameters and no output schema, the description is under-specified. It fails to explain how payment is made via payment_signature, what the default time window is, or the nature of the response. This leaves significant gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context about the data (address-specific events) but does not elaborate on individual parameters like limit, since_iso, or payment_signature. With 75% schema coverage, the description provides marginal semantic value beyond the schema's existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it returns pulse events (whale, sentinel signal, news, permissioned-domain) referencing a specific XRPL address. It distinguishes itself from siblings by name-dropping xrpl_sentinel_scan and adding 'event history' as a complement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use this tool: for address-specific event history, complementing xrpl_sentinel_scan. However, it does not explicitly state when not to use it or name alternative tools like xrpl_pulse_recent_events, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It mentions "Free" and lists output metrics, which adds some context, but it does not disclose auth requirements, rate limits, or behavior for omitted parameter values. The read-only nature is implied but not explicitly stated, and no safety profile is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that delivers the key purpose and a list of provided metrics. Every word is informative, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description lists key metrics but does not explain the full response structure or behavior when all pairs are returned. Given no annotations, the description is adequate but not exhaustive for a complete contextual picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'pair' with 100% coverage, explaining the format (e.g., 'XRP/RLUSD') and that omitting it returns all pairs. The description adds no additional parameter semantics beyond using the word 'Per-pair', which aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it retrieves per-pair DEX volume metrics on XRPL, listing specific data points (24h/7d volume, fill counts, orderbook vs AMM split, annualized run rate). This verb+resource combination distinguishes it from sibling telemetry tools like settlement or snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly say when to use this tool versus alternatives, nor does it mention any exclusions. The purpose is implied by the name and description, but there is no direct guidance on suitable use cases or comparisons to other telemetry tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the tool is free and provides daily summaries with specific output fields, but does not explicitly mention whether it is a read-only operation, whether authentication is required, or any rate limits. The behavior is largely predictable given its summary nature, but the description alone is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with 'Free.' and 'Daily', and every phrase contributes meaning: cost, frequency, and content. It is concise, well-structured, and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with one optional parameter and no output schema. The description provides the core content (per-ticker metrics, supply share) and frequency, while the schema covers the lookback parameter. However, it does not specify the output format or any limitations, though for a simple summary tool this is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'days' with its default and maximum, giving 100% schema coverage. The description does not add any additional meaning or context about this parameter, so it adds no value beyond the schema. Per the rubric, baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and informative: 'Daily ETF flow summary: per-ticker AUM with day-over-day delta, growth rate, and aggregate XRP supply share.' It clearly states the tool's function (summarizing ETF flows) and the exact metrics returned. This distinguishes it from sibling flow tools like xrpl_flows_scan or xrpl_flows_correlation, which are not ETF-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context (free, daily) but does not explicitly state when to use this tool versus alternatives. It implies usage for obtaining ETF flow summaries, but there is no guidance on when not to use it or which sibling tool to choose instead. Thus, usage is only implied, not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the cost ($0.10) and the returned fields, but does not mention authentication requirements (beyond the payment_signature parameter), error handling, or side effects. The payment disclosure is useful, but other behavioral aspects remain unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the cost and purpose. Every sentence serves a function: the first announces the paid nature, the second defines the action and the return structure. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does well to list the return fields (activity_score, activity_level, confidence, etc.). It covers the core functionality and cost but lacks details on error conditions or rate limits. For a classification tool with clear schema, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters (100% coverage). The description adds value by explaining the payment context ('Paid ($0.10 USD)') which clarifies the purpose of the payment_signature parameter, and by linking the address to wallet classification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Classify an XRPL wallet') and the resource, distinguishing it from sibling tools like event or trust-related scans. It also enumerates the output, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, nor any prerequisites beyond the paid requirement. The description is purely declarative and does not mention exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 $0.10 USD cost and the 25-record cap, adding useful context. However, it does not explain how the payment_signature parameter facilitates payment or whether this operation mutates any state, trusting the reader to infer the monetary requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the paid status and core function. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description covers the essential function, the result limit, and the cost, making it adequate for a simple two-parameter tool. It could be more complete by describing the response structure or prerequisites, but the core retrieval task is fully clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions), so the baseline is 3. The tool description adds the context of 'prior recorded scans' for the address and the cost implication for payment, but it does not provide additional syntax or format details beyond the schema's 'XRPL r-address' and 'x402 payment header'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact function: 'Return up to 25 prior recorded scans for an address to read score trajectory over time.' This uses a specific verb, identifies the resource (recorded scans), and clarifies the purpose (score trajectory), distinguishing it from the current-scan sibling xrpl_sentinel_scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'prior recorded scans' implies a historical-analytics use case, but the description does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided, leaving the usage context to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of revealing behavior. It discloses the return components (parent funder, credential types, gated assets, plain-English summary, confidence tier), which gives the agent a clear idea of what the tool does. It does not mention error handling, side effects, or rate limits, but for a seemingly read-only attribution tool, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence, front-loaded with 'Free' and the core purpose, followed by a colon-separated list of deliverables. Every word adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no nested objects, no output schema), the description adequately covers the key aspects by listing the output components. It lacks details on error cases or result format, but the provided information is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter operator_address is fully documented in the schema with pattern and description (100% coverage). The description adds minimal parameter-specific meaning beyond stating it targets one operator, so the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides institutional attribution for a single PermissionedDomain operator, listing specific output components (parent funder, credential types, gated assets, summary, confidence tier). It uses a noun phrase rather than an explicit verb, and does not explicitly differentiate from similar sibling tools like xrpl_trust_operator_drilldown, but the details make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one PermissionedDomain operator' implies this is for per-operator attribution queries, and 'Free' hints at cost considerations. However, there is no explicit guidance on when to prefer this over alternatives like xrpl_trust_operator_drilldown or xrpl_trust_list_operators_index, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and adds meaningful behavioral context. It explains the semantics of net_usd and net_direction, including the role-aware definition of accumulation. However, it omits details like data latency, output structure, or rate limits, so it is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every clause contributes. The first sentence delivers purpose and scope; the second clarifies key definitions. 'Free' is slightly extra but not distracting, and the overall structure is clean and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description explains the purpose and two key output fields but leaves gaps: it does not describe the overall response structure (e.g., rows per entity per day), how entities are selected, or any time-related nuances. The single parameter is simple, but the output behavior is under-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'days' with a clear default and maximum. The description adds no additional parameter-specific information, so it meets the baseline without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('scoring') and a clear resource ('per-entity accumulation vs distribution') with entity types explicitly listed. It distinguishes itself from sibling tools like exchange_flow_delta or whale_flow_24h by focusing on entity-level positioning from labeled whale events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for entity-level accumulation/distribution analysis, but does not explicitly name alternatives or exclusion conditions. It lacks guidance on when to prefer this tool over siblings such as xrpl_pulse_exchange_flow_delta, making the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that the tool is free, forward-looking, and includes certain data components, but does not mention data source, update frequency, precision, or limitations. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently conveys 'Free', 'Forward-looking', and the three key data components without filler. Every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description outlines the expected content well (monthly unlock schedule, relock history, net release rate). However, it lacks detail on the exact output structure or temporal range, so not fully complete for an agent forming expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per rubric. There is nothing to add beyond the empty schema, and the description accurately implies no user input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides a 'Forward-looking Ripple XRP escrow release calendar' with specific components (monthly unlock schedule, relock history, net release rate). This clearly identifies the resource and distinguishes it from sibling tools focused on events, flows, or trust metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is given. The description implies use when needing XRP escrow release schedules or related metrics, but it does not state exclusions or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the contents of the output and notes 'Free,' implying no cost. However, it does not explicitly state that the operation is read-only, describe response format, or explain the meaning/accuracy of 'snapshot freshness' beyond a label. It adds some context but still leaves open basic behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the 'Free' note and then lists the key metrics. Every word contributes to understanding, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple zero-parameter interface and absence of an output schema, the description lists all the main metrics returned and implies a current snapshot with 24h coverage. It is adequate for an agent to invoke the tool and understand the general output, though it could clarify whether it's a live view or historical range and how 'freshness' is computed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so schema coverage is effectively 100%. No parameter explanations are needed, and the baseline of 4 for no-parameter tools applies. The description correctly focuses on output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides an XRPL network summary and enumerates the exact metrics included (funded addresses, trustline count, offer count, 24h active addresses, snapshot freshness). This distinguishes it from sibling tools focused on events, trust, or telemetry, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, nor any exclusions. It implies use for network-level statistics through its name and metric list, but does not name sibling tools or state that other tools should be used for specific other needs. The guidance is entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the analytical behavior (categorization logic, correction of misinterpretation, and RLUSD face value units), which adds useful context. However, it does not address whether the operation is read-only, requires permissions, or has rate limits—typical transparency concerns for tools without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by details on output categories and interpretation. The opening 'Free.' is slightly tangential but still informative. No wasted words; each sentence contributes to understanding the tool's behavior and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description does an excellent job of explaining the return structure (by_exchange, to_labeled_non_exchange, unattributed, to_exchange_pct, mint_context) and the interpretive context. It fully equips an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'days', is fully documented in the schema with description, default, and max values. The tool description does not add any additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it tracks RLUSD mint-to-CEX distribution by splitting outgoing RLUSD into by_exchange, to_labeled_non_exchange, and unattributed categories. This is specific to RLUSD mint distribution, distinguishing it from sibling tools like cex_attribution or exchange_flow_delta. The purpose is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool—when analyzing fresh RLUSD mints to avoid misinterpreting them as XRP sell-pressure. It implies the tool is the correct choice for RLUSD distribution analysis, but it does not explicitly mention alternatives or exclusions. Context is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is free, limited to top 200 tokens, and returns scores per dimension with a 0-10 scale and color coding. This gives a clear picture of output and cost, though it does not mention rate limits or authentication requirements, which are not critical for a read-only analytics tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'Free.' and clearly structured. It efficiently conveys the core value, scope, output format, and filtering options without any redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description explains the return style (0-10 scores with green/yellow/red) and the token scope (top 200). It also mentions filtering, which together covers the essential context for a user to understand what this tool returns. Minor details like the exact response structure or sort behavior are left to the schema, but the description is sufficient for initial understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all four parameters with detailed descriptions, achieving 100% coverage. The description merely restates the filtering options (issuer wallet or currency code) without adding new semantic details beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a unique purpose: providing per-token health scores for XRPL tokens across five named dimensions. It distinguishes itself from sibling tools by focusing on health scores rather than events, flows, or trust domains, and the verb 'health scores' is specific and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for token health assessment, noting the coverage of top 200 tokens and the ability to filter by issuer or currency. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, leaving usage guidance mostly inferred from the scope and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the payment prerequisite and return shape ('Same shape as xrpl_telemetry_snapshot'), but does not discuss error handling, what happens with an unpaid invoice, or any rate limiting. This is minimal but useful context for a simple one-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the paid-flow context, then states the action and shape reference, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description is largely complete: it covers purpose, timing, and return shape via the sibling reference. It does not detail the entire paid flow, but sibling names like xrpl_telemetry_get_quote and xrpl_telemetry_get_status provide the surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'Paid invoice id' already describing invoice_id. The description reinforces that the invoice must be paid but adds no significant semantic detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('full Telemetry snapshot payload'), plus a clear condition ('once invoice is paid'). The phrase 'Paid flow step 3' and 'Same shape as xrpl_telemetry_snapshot' distinguish it from sibling telemetry tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: after an invoice is paid, as 'step 3' of a paid flow. It also notes 'no extra charge.' However, it does not explicitly name alternatives or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is 'Free' and lists the data it returns, which is useful. However, it does not mention whether authentication is needed, rate limits, or if the data is a snapshot or live. For a read-only rollup, this is moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the key facts ('Free', 'XRPL settlement volume rollup') and then lists the specific metrics. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return values by listing the metrics (24h/7d/30d volumes, annualized run rate, payment counts). It is complete for a no-parameter tool, though it could specify the response format or whether data is cumulative. Overall, it provides sufficient context for an agent to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description correctly does not invent parameter details, and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'settlement volume rollup' and specifies the exact outputs: 24h/7d/30d USD volume, annualized run rate, and payment counts, across XRP and RLUSD. This distinguishes it from the sibling 'xrpl_telemetry_settlement_series' tool, which likely provides a time series rather than aggregate totals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving settlement volume totals, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. The 'Free' note provides cost context but not situational guidance. Thus, usage is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the cost ($0.10 USD) and the scope of data, but does not explicitly state that the operation is read-only or explain how the payment_signature parameter is used. This is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a cost lead-in, a colon, and a list of data categories. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the three key data categories returned. It also mentions payment. It is incomplete about return format or payment mechanics, but for a deep-dive tool with only two parameters, it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reiterates the domain_id format ('64-hex ID') but adds no new meaning beyond the schema for either parameter. It does not explain the payment_signature further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a deep dive on a single PermissionedDomain identified by 64-hex ID, listing specific data categories (lifecycle history, permissioned market activity, DID/TOML identity). This distinguishes it from sibling list/scan tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Deep dive on one PermissionedDomain' provides clear context for when to use this tool—when detailed information on a specific domain is needed—but it does not explicitly name alternatives or exclusions. Since no explicit when-not-to-use is given, it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses the cost ($0.10 USD), the fact that it lists all domains (scope), the included fields (owner, accepted credentials, institutional issuer counts), and pagination behavior. This is substantial value beyond what structured fields provide, though it does not mention rate limits, authentication, or read-only status explicitly. The cost and pagination disclosures are particularly useful for an agent deciding whether to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the critical cost information and immediately states the action and scope. It includes all necessary details (network, object type, returned fields, pagination) without any wasted words. It is concise, scannable, and every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a list operation with three parameters, no output schema), the description is fairly complete. It specifies the returned fields and pagination, and the cost is stated. It does not describe the response envelope (e.g., how pagination metadata is represented) or potential errors, but these are less critical for a list tool. The description provides adequate context for an agent to invoke the tool correctly, though slightly more detail on offset/limit semantics would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33% (only payment_signature has a description). The tool description adds some semantic value by mentioning 'Paginated' (suggesting limit/offset purpose) and 'Paid' (implying payment_signature's role), but it does not explain how the parameters interact (e.g., default limit, offset for pages, or that payment_signature is required for payment). The description adds a bit of meaning but does not fully compensate for the undocumented limit and offset parameters, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all XRPL PermissionedDomain (XLS-80) objects on mainnet with owner, accepted credentials, and institutional issuer counts.' It uses a specific verb ('list all') and resource ('XRPL PermissionedDomain'), and the phrase 'all' distinguishes it from sibling tools like xrpl_trust_get_domain, which likely retrieves a single domain. The mention of 'on mainnet' and XLS-80 further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is a paid, paginated listing of all domains, so it should be used when a complete enumeration is needed. However, it does not explicitly mention alternatives or when not to use it, such as 'use xrpl_trust_get_domain for a specific domain.' The cost and pagination provide some contextual guidance, but the lack of explicit exclusions or alternative tool references keeps this at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool is free and lists the data categories included, but it does not address output format, latency, caching, or any side effects. Since it's a briefing aggregator, it likely performs reads only, but this isn't explicitly stated. The description provides moderate transparency about scope but not about operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a concise, front-loaded structure. It lists the content areas in a scannable format and ends with the efficiency value proposition. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no input parameters and no output schema, making the description the primary source of context. The description enumerates the coverage areas (market posture, positioning, RLUSD health, supply pressure, RWA, whale activity, alerts), which is fairly comprehensive. However, it lacks details on how to interpret the briefing or whether it covers historical or real-time data. Given the aggregation nature, this is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there is nothing to explain. The description adds context about the tool's output scope, which helps the agent understand what will be returned, but parameter-specific semantics are not needed. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines a composite desk briefing tool that aggregates market posture, narrative, positioning, RLUSD health, supply pressure, RWA market, whale activity, and alerts. It explicitly states it replaces 6-8 separate tool calls, distinguishing it from the more granular sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: when a broad composite briefing is needed. The phrase 'One call replaces 6-8 separate tool calls' signals it's a consolidation tool, though it doesn't explicitly mention when not to use or name alternative tools for specific metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the tool is free, limits data to institutional/exchange wallets, and returns aggregates, corridors, and a coverage block. It does not explicitly state read-only behavior or potential limitations like rate limits, but it provides meaningful context about output composition and data scope, going beyond a mere restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using three short, front-loaded segments that convey value ('Free'), purpose, and constraints. Every phrase adds information without redundancy, and the structure allows quick comprehension by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter query tool without annotations or output schema, the description gives a useful overview of the result contents, mentioning the key output types and data scope. It might be lacking detail on the format of 'coverage block' and any data freshness or pagination behaviors, but the core functionality is adequately described and sufficient for most selection and invocation purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (window_days and top_corridors) with clear descriptions. The tool description does not add any additional parameter semantics beyond what the schema already states, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing XRPL cross-border settlement flow, listing specific output components (country-pair aggregates, top corridors, coverage block) and a scope constraint (institutional/exchange wallets only). This distinguishes it from sibling tools like xrpl_flows_scan or xrpl_flows_correlation, which focus on different flow analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying the data scope ('Institutional/exchange wallets only') and stating it is free, implying it is appropriate for cross-border flow queries. It does not explicitly name alternatives or exclusion conditions, but the specific focus on cross-border settlement and the output types provides enough guidance to differentiate from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the $0.10 payment, which is critical, and lists the return payload. However, it does not explicitly state whether the operation is read-only, idempotent, or if there are rate limits or side effects. For a paid scan tool, this is a noticeable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with 'Paid' and 'Per-ETF deep dive,' then efficiently lists tiers/tickers and the return payload. Every clause serves a purpose; no wasted words despite the dense information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex paid tool with no output schema, the description covers cost, target tickers, tiers, and return fields. It does not describe error handling or invalid-ticker behavior, but the essential operational context—ticker universe, cost, and outputs—is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value by enumerating the complete tracked ticker universe by tier, going beyond the schema's simple examples. It does not add info about payment_signature beyond the schema's 'x402 payment header,' but the paid nature is already highlighted in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: a per-ETF deep dive for tracked XRP-exposure ETFs, enumerating three tiers and example tickers. It distinguishes itself from sibling tools like etf_flow_summary by emphasizing 'deep dive' vs. summary, and the return contents (metadata, AUM, history, flow delta) further clarify its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this for per-ETF detail across specific US and European ETF tiers, as opposed to aggregate or correlation tools. However, it does not explicitly name alternatives or state 'when not to use,' so it falls short of full alternative/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses pricing (free), scope (cross-issuer), and the nature of the data (daily series, mint/burn counts, net inflow). It doesn't mention auth or rate limits, but for a read-only data retrieval tool, this is sufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, zero wasted words. The leading 'Free.' is efficient and informative. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description sufficiently explains the return content (mint/burn counts and net inflow) and positions the tool within the sibling set. It could add a bit more about the output format, but it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter documentation ('days' with description 'Trailing days.'), so the baseline is 3. The description adds no extra semantics about the 'days' parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: providing a 'cross-issuer daily RWA flow series' with specific metrics (mint/burn event counts per day and USD-pegged net inflow aggregate). It also distinguishes itself from a paid per-issuer scan, so it's unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the complementary relationship to the paid per-issuer scan, giving clear context for when to use this free cross-issuer tool. However, it doesn't explicitly name the alternative tool or list exclusions for other sibling tools, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral context: the tool is labeled 'Free', it aggregates trailing 24h data, and it explicitly excludes specific addresses from the response. These facts go beyond a simple rephrasing of the tool name and help the agent understand the privacy/scope characteristics, though it doesn't mention authentication, rate limits, or potential output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using three short fragments: 'Free.', the enumerating list of output components, and the explicit exclusion note. Every phrase adds distinct value, with no repetition of the tool name or obvious filler. The structure front-loads the key concepts and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no output schema, and no annotations, the description provides adequate context for an agent to understand what the tool does and what it returns. It lists all requested output components (total USD, tx count, top labels, per-currency breakdown) and clarifies the time window (trailing 24h) and a key limitation (no addresses). For a simple zero-param aggregate tool, this is complete enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description compensates by explaining the output semantics (aggregate fields and intended time window), which is more than the empty schema provides. It clarifies what data the agent will receive, effectively documenting the implicit 'inputs' of the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a trailing 24h whale Payment aggregate with specific components (total USD, tx count, top labels, per-currency breakdown). It distinguishes itself from sibling tools by emphasizing the aggregate nature and explicitly noting that no specific addresses are returned, which sets it apart from address-centric tools like xrpl_pulse_events_by_address or xrpl_pulse_recent_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a high-level whale payment summary without needing address-level details. The 'No specific addresses returned' provides a hint about when NOT to use it (i.e., when individual addresses are needed), but it lacks explicit guidance on when to prefer this tool over alternatives such as exchange_flow_delta or network_stats. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states that this is a polling operation, includes 'no extra charge' (cost transparency), and lists the returned fields. It does not explicitly mention side-effect-free behavior or error conditions, but 'poll' and 'status' imply a read-only operation, making this reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads context ('Paid flow step 2 (no extra charge)') and then states the action and return values. Every sentence earns its place, with no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter polling tool with no output schema, the description covers the workflow step, the expected input, and the output fields. No critical information is missing for an agent to correctly select and invoke the tool, making it complete within its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter already described as 'Invoice id from get_quote.' The description adds no further parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Poll invoice status from get_quote' with a specific verb and resource, and distinguishes itself as 'Paid flow step 2' and 'Returns paid (bool), amount, ledger_index, and expiry.' This clearly identifies the tool's function and its relationship to sibling tools like get_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by labeling this as 'Paid flow step 2' and referencing 'get_quote' as the source of the invoice_id. It implies when to use it (after getting a quote), but does not explicitly mention when not to use it or name alternatives like get_results, so it stops 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states that the tool is 'Free' and describes the exact computation (exchange-flow delta and DEX volume) over a defined window. While it does not detail output format or data sources, the read-only analytical nature is clear, and the description adds meaningful context about the launch-window scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is compact and front-loaded with 'Free' followed by the core analysis details. Every word contributes to the meaning, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the essential context: the time window, metrics, and subject. However, it leaves 'tracked XRP-exposure ETF' and the exact definition of 'L' slightly implicit, which could be clarified. Overall, it is sufficiently complete for a zero-param analytical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with no parameters, so the baseline is 4. The description reinforces that the analysis is fixed around ETF launch dates without requiring user input, making parameter documentation unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Per-ETF launch-window analysis: [L-30, L+30] exchange-flow delta and DEX volume around each tracked XRP-exposure ETF launch date.' This specifies the exact computation, metrics, and scope, distinguishing it from sibling tools like xrpl_flows_etf_flow_summary and xrpl_flows_exchange_flow_delta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when one needs to analyze exchange-flow delta and DEX volume around XRP ETF launch dates. It does not explicitly mention alternatives or exclusions, but the specific use case is evident from the description, earning a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the paid nature, pricing tiers, that filtering is bound into the token (implying immutability after purchase), and the output format. It does not detail payment failure or refund policies, but covers the essential behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey cost, output, and core behavior with zero fluff. The pricing is front-loaded, and every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers cost, output (JWT and ws_url), and the binding effect of filters, which is sufficient for a purchase tool. No output schema exists, so the explicit return description is valuable. It does not explain how to use the token, but that is likely covered by a separate streaming tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters, but the description adds meaning by explaining that source/signal/min_usd filters are 'bound into the token' at purchase and by associating duration tiers with concrete prices. This goes beyond the baseline schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Buy a time-boxed WebSocket subscription to live Pulse events' with a specific verb and resource, distinguishing it from sibling query tools. Also mentions the return values (stream_token JWT and ws_url).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is for paid live streaming with tiered pricing, implying use for real-time Pulse events. It does not explicitly state when-not-to-use or list alternatives, but the purpose is distinct from the many data-query siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the tool is paid ($0.10 USD total), asynchronous (returns invoice info rather than results), and requires a subsequent payment step. It does not elaborate on failure modes or idempotency, but covers the essential behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three crisp sentences, front-loaded with 'Paid flow step 1'. Each sentence adds distinct value: cost, what it returns, and the subsequent workflow. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, the description is remarkably complete. It explains the return fields, the payment requirement, and the exact sequence of follow-up calls, so an agent has everything needed to invoke it correctly in the broader paid flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is completely empty (0 parameters, 100% schema coverage), so there are no parameter semantics to clarify. The description appropriately focuses on the return values instead, which is the relevant semantic information for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts an async invoice flow as step 1 of a paid flow, and specifies the exact return fields (invoice_id, payTo, deepLink, QR, expiry). It also distinguishes itself from sibling tools by explicitly positioning itself relative to get_status and get_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context: use this first in a paid async flow, then pay via XRPL, then poll get_status, then call get_results. It does not explicitly list when not to use it, but the sequential instructions serve as strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![xrpl-utilities-mcp MCP server](https://glama.ai/mcp/servers/XRPL-Utilities/xrpl-utilities-mcp/badges/card.svg)](https://glama.ai/mcp/servers/XRPL-Utilities/xrpl-utilities-mcp)

Score Badge

Copy to your README.md:

[![xrpl-utilities-mcp MCP server](https://glama.ai/mcp/servers/XRPL-Utilities/xrpl-utilities-mcp/badges/score.svg)](https://glama.ai/mcp/servers/XRPL-Utilities/xrpl-utilities-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/XRPL-Utilities/xrpl-utilities-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server