Read-only XRP Ledger MCP tools with proof-annotation envelopes and signed daily snapshots.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 15 of 15 tools scored. Lowest: 3.5/5.
Every tool targets a distinct resource and action, from amendments and AMM pools to RLUSD supply and whale events. Even the two whale-related tools have clear boundaries: events include all events, while watchlist focuses on tagged-watchlist events. No two tools appear to overlap in purpose.
All tools follow a consistent get_<resource> pattern, with the sole exception being verify_snapshot_signature, which correctly uses a verb for a verification action. The naming is uniform, readable, and predictable throughout.
15 tools is at the upper end of the ideal range, but each tool covers a distinct aspect of the XRPL dashboard domain, from ledgers and RLUSD to RWA and UNL. The scope feels well-calibrated for a read-only dashboard server, with no redundant or trivial tools.
The tool set provides comprehensive read-only coverage of the dashboard's features, including amendment status, AMM pools, ledger stats, MPT, RLUSD supply/flow, RWA pools/families, token attestations, UNL, whale events/watchlist, and signed snapshots with verification. No obvious gaps exist for the stated purpose.
get_amendment_statusAInspectReturn the current amendments state (enabled / in-flight /
superseded / unrecognized-enabled) with cross_check_status
derived from the responding node's feature-RPC vs Amendments
ledger-object concurrence. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 cross_check_status is derived from the node's feature-RPC vs Amendments ledger-object concurrence and that results are wrapped in a proof envelope, adding useful context beyond a simple getter. However, it does not explain error behavior, prerequisites, or what the proof envelope contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the main purpose ('Return the current amendments state') and then adds necessary detail. It is efficient and avoids fluff, but the structure is slightly convoluted with multiple clauses, though not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description explains the core return values (amendment states and cross_check_status) and mentions the proof envelope. It is missing details on the exact structure of the proof envelope and semantics of 'unrecognized-enabled', but it is sufficiently complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameters, and it instead focuses on the output semantics, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current amendments state, enumerates the specific states (enabled/in-flight/superseded/unrecognized-enabled), and mentions the derived cross_check_status. This distinguishes it from sibling tools like get_unl_status or get_ledger_stats, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need current amendment status, but it does not explicitly state when to use it over other tools or provide any exclusions/alternatives. It mentions no competing tools, leaving usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_amm_poolAInspectReturn the single ranked-pool row for one AMM account from the amm_ranked_pools snapshot. Raises when the account is absent (unranked, below thresholds, or newer than the last snapshot). Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| amm_account | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses failure behavior ('Raises when the account is absent') and response format ('Wrapped in the proof envelope'). It does not mention permissions or side effects, but for a read-only query this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, followed by exception behavior and response wrappings. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose and error cases but does not describe the contents of the 'single ranked-pool row' or the proof envelope structure. Since there is no output schema, more detail about the return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the amm_account parameter. However, the parameter name and title ('Amm Account') are self-descriptive, and with a single required string parameter, the lack of additional semantics is not critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Return'), the specific resource ('the single ranked-pool row for one AMM account'), and the source ('amm_ranked_pools snapshot'). It is distinct from sibling tools like get_amm_top_by_tvl by focusing on a single account rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for a single AMM account and raises if the account is unranked, below thresholds, or newer than the last snapshot. This implies when to use it (for known ranked accounts) but does not explicitly mention alternatives such as get_amm_top_by_tvl for top listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_amm_top_by_tvlAInspectReturn the top-N ranked AMM pools by tvl_usd from the same snapshot /pools reads. NULL-tvl rows sort last. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses useful behaviors: NULL-tvl rows sort last, the data is from the same snapshot/pools reads, and the response is wrapped in a proof envelope. This goes beyond the bare operation but doesn't cover error/auth/rate-limit details, so a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the operation, and no filler. Each sentence contributes a distinct fact (ranking, null ordering, envelope).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description is complete: it states what is returned (top-N pools), ordering behavior, consistency with the snapshot, and the response envelope. It doesn't elaborate the envelope's internal fields, but that appears to be a shared convention among the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only has 'limit' (integer, default 10) with 0% description coverage, but the description's 'top-N' maps N directly to the limit parameter and the TVL ranking gives it meaning. It doesn't specify bounds or edge behavior for limit, but it compensates reasonably for a single simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('AMM pools'), with clear ranking criterion ('tvl_usd') and scope ('top-N'). This distinguishes it from the sibling get_amm_pool, which targets individual pools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes clear context: the results are top-ranked by TVL and come from the same snapshot/pools reads, so an agent can infer when to call it for rankings. However, it does not explicitly name alternatives or state when not to use it, so it stops 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.
get_ledger_statsAInspectReturn the last-validated ledger stats (index, close time,
server state, load factor, complete range, build). Wrapped in
the xrpldashboard proof envelope; envelope source is derived from
the actual URL host (local_rippled for loopback / private LAN,
remote_rippled:<host> otherwise) — never hardcoded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses meaningful behavior: the result is wrapped in a proof envelope, and envelope source is dynamically derived from the URL host ('local_rippled' vs 'remote_rippled:<host>'), never hardcoded. This adds useful context beyond the bare function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states what is returned, the second adds essential envelope detail. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the key aspects: the exact data returned and the envelope wrapping behavior. It lacks any note about error conditions or why this tool exists, but for a simple zero-parameter getter, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. Per the rubric, this is a baseline 4. The description's mention of envelope source relates to the tool's behavior rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Return') and resource ('last-validated ledger stats'), and enumerates the specific stats (index, close time, etc.). It distinguishes itself from siblings by focusing on ledger stats and including the proof envelope detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No alternatives or exclusions are mentioned. The only context provided is envelope source derivation, which is 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.
get_mpt_snapshotAInspectReturn the MPT snapshot dict (issuances / by_class / total). Not third-party-naming — no dispute_contact_url. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 return envelope ('Wrapped in the proof envelope') and content exclusions (no dispute_contact_url). It does not mention side effects, auth, or error behavior, but for a simple read-only getter, this level of transparency is adequate and adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each providing substantive information: what is returned, what is excluded, and the envelope. There is no redundancy or fluff, and key facts are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately explains the return value (issuances, by_class, total) and the proof envelope. It also places the tool in the context of the snapshot family by noting what it does not include. A slightly higher score would require more detail on return types or formats, but current detail is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids parameter explanations, and its mention of the return structure is relevant. No param info is needed since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the MPT snapshot dict with specific fields (issuances / by_class / total). It also distinguishes itself from sibling tools by explicitly noting the absence of third-party naming and dispute_contact_url, making it unique among the snapshot family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it returns the raw MPT snapshot without third-party naming, so if a consumer needs dispute_contact_url or third-party data, they should use a different tool. This exclusion criterion provides some guidance, though it does not explicitly name alternatives or state when not to use this tool beyond that specific case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rlusd_flow_24hAInspectReturn the last finalized 24h XRPL net-change from rlusd_supply_history. freshness_contract='finalized_only' is the machine-readable form of the R1/R2 finalized-window rule. cross_check_status derived from stored vs supply-diff pair. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 enforces a finalized-only freshness contract, derives a cross_check_status, and wraps results in a proof envelope—valuable context beyond simply 'returns data.' It does not describe error conditions or access requirements, but these are less critical for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no fluff. The second sentence adds meaning by explaining the freshness contract and proof envelope, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool, the description provides the key output (net-change), the source (rlusd_supply_history), and important qualifiers (finalized, proof envelope). Without an output schema, it could specify the return format more explicitly, but the domain-specific terms are sufficiently explained for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. Per the baseline rule for 0 params, this scores a 4; the description correctly avoids inventing parameters and focuses on the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Return the last finalized 24h XRPL net-change from rlusd_supply_history,' which is a specific verb+resource+scope. It clearly distinguishes from siblings like get_rlusd_supply (which likely returns current supply) and get_signed_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it name sibling tools. However, the specific 'last finalized 24h net-change' phrasing implies its intended use case. With no parameters, usage is straightforward, but there is no explicit comparison to other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rlusd_supplyAInspectReturn the current cross-chain RLUSD supply (Ethereum + XRPL) from the same PG mirror /rlusd reads. Honest-partial when either chain errored. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 reveals key traits: 'Honest-partial when either chain errored' and 'Wrapped in the proof envelope', which go beyond a simple read-only hint. This adds useful context about error handling and output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each providing distinct value: purpose, error behavior, and output wrapping. No redundant or extraneous words appear, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description covers the core functionality, error handling, and proof envelope. It does not detail the exact return format, but the essentials are present and the behavior is clear enough for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage (empty schema). Per the rubric, a baseline of 4 applies since there are no parameters for the description to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'current cross-chain RLUSD supply (Ethereum + XRPL)', identifying a specific verb and resource. It distinguishes this from sibling tools like get_rlusd_flow_24h by mentioning 'supply' rather than flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The purpose is implied by the name but no guidance is provided for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rwa_familiesAInspectReturn every rwa_family row with attributed pool count. Data
payload includes dispute_contact_url. Wrapped in the proof
envelope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the data is wrapped in a proof envelope and includes a specific field, which is useful behavioral context. However, it does not mention potential caveats like pagination, response size, or access requirements, though the 'Return' wording implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences with no filler. Key information (what is returned, the specific field, the proof envelope) is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and is a straightforward list endpoint, the description provides sufficient context about the returned data and its envelope. The absence of explicit return format documentation is mitigated by the description's clarity about the payload contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the description does not need to explain input semantics. Per the rubric, a baseline of 4 is appropriate since there are no params to document, and the description adds clarity about the output contents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Return') and resource ('every rwa_family row' with 'attributed pool count'). It specifies a unique output field, dispute_contact_url, and differentiates from sibling tools like get_rwa_pools by focusing on rwa_families.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need the complete list of rwa_family rows with their pool counts and the dispute contact URL. No explicit guidance on when not to use it or alternatives is given, but the purpose is self-evident within the context of sibling read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rwa_poolsAInspectReturn every attributed RWA pool with provenance + TVL. Data
payload includes dispute_contact_url. Wrapped in the proof
envelope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation ('Return') and adds context about the payload (dispute_contact_url, proof envelope), but it does not explicitly state safety characteristics like whether it requires authentication or if it is a read-only call. This leaves some ambiguity, though it is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly worded, and front-loads the core purpose. Every piece of information (provenance, TVL, dispute_contact_url, proof envelope) adds value without redundancy. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no parameters, the description provides useful context about the response structure (dispute_contact_url, proof envelope). However, terms like 'provenance' and 'attributed' are not elaborated, so the agent may not fully understand the semantics. For a simple getter, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description does not need to explain parameters, but it does indirectly describe the output fields, which adds some semantic value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and clearly identifies the resource ('every attributed RWA pool') with the key attributes (provenance + TVL). It also distinguishes this from sibling tools like get_amm_pool or get_rwa_families by focusing on RWA pools and their data payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need all RWA pools with provenance, TVL, and the dispute contact URL) but does not explicitly mention when to prefer it over alternatives or provide exclusions. It is clear enough that an agent can infer the context, but there is no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_signed_snapshotAInspectReturn the Ed25519-signed daily snapshot for date_str
(ISO YYYY-MM-DD) wrapped in the proof envelope. Absence raises —
the walker has not produced this date yet, or the date predates
the chain start.
| Name | Required | Description | Default |
|---|---|---|---|
| date_str | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses a key behavior: absence raises an exception due to unproduced date or pre-chain start. This adds meaningful error-handling context beyond the schema. It doesn't mention auth or rate limits, but for a simple getter, the provided behavior is a solid baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the core function and parameter format, the second covers edge-case behavior. Every word earns its place, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description covers purpose, parameter format, and error behavior, which is largely complete. A slight gap is the absence of detail about the proof envelope structure, but given the simplicity, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines date_str as a string, but the description adds the ISO YYYY-MM-DD format, making the parameter fully understood. Since schema coverage is 0%, the description fully compensates, leaving no ambiguity about the required input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns an Ed25519-signed daily snapshot for a given date, using a specific verb ('Return') and resource. It distinguishes itself from siblings by focusing on 'signed snapshot' and the date parameter, differentiating from verify_snapshot_signature and get_mpt_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use for retrieving signed daily snapshots, and notes absence raises an error for future or pre-chain dates. While it doesn't explicitly name alternatives, the sibling tools' names imply distinct purposes, and the description contexts are sufficient for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_token_attestationAInspectReturn the attestation tier (verified / self-described / null)
for one (currency, issuer) pair. Data payload includes
dispute_contact_url — first tool to name a third party. Wrapped
in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer | Yes | ||
| currency | Yes |
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 does add useful context: the data payload includes `dispute_contact_url` and is 'wrapped in the proof envelope.' However, it omits important behavioral details such as error responses, whether the tool is read-only (implied but not stated), and what 'null' tier means. The disclosure is partial, not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, with no redundant filler. However, the phrase 'first tool to name a third party' is odd and potentially confusing in a tool reference; it reads like a developer note rather than user-facing guidance. Still, the description is short enough that each sentence mostly earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description does a decent job of indicating what is returned (attestation tier, a payload with `dispute_contact_url`, wrapped in a proof envelope). Yet it leaves gaps: no explanation of what the proof envelope is, how to interpret 'null', or any operational context. For a simple lookup tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (neither parameter has a description), so the description must compensate. It only offers 'for one (currency, issuer) pair,' which reinforces that the two parameters are a paired set, but it does not explain expected formats (e.g., ISO codes, strings), examples, or how to handle invalid values. The parameter names are self-explanatory, but the description adds minimal semantic value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return the attestation tier (verified / self-described / null) for one (currency, issuer) pair.' This is a specific verb+resource+scope structure that immediately distinguishes it from sibling tools like get_amendment_status or get_amm_pool. The mention of a specific payload field further clarifies intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: you use this tool when you need attestation for a specific (currency, issuer) pair. It does not explicitly provide alternatives or when-not-to-use scenarios, but the 'one pair' phrase hints at the intended granularity. There is no mention of when to prefer sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_unl_statusAInspectReturn the current UNL composition (both published lists, overlap, expiry-days). Honest-partial when a list fetch fails. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses an important failure mode ('Honest-partial when a list fetch fails') and response wrapping ('Wrapped in the proof envelope'), which are valuable beyond the empty schema. However, it does not mention permissions or rate limits, though these are less critical for a read-only status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary purpose first, then adds the failure behavior and envelope wrapping. Every phrase adds useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool, the description covers the main return content, the failure mode, and the response envelope. It does not detail the exact JSON shape, but that is likely unnecessary given the simplicity and the proof envelope reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on output content rather than parameter syntax, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and identifies a clear resource ('current UNL composition') with detailed content ('both published lists, overlap, expiry-days'). This clearly differentiates it from sibling tools like get_amendment_status or get_ledger_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The resource is implied by the name, but the description does not mention any exclusions or compare with siblings such as get_signed_snapshot or verify_snapshot_signature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_whale_eventsAInspectReturn the last N XRP-denominated whale events + tagged-watchlist events (trustset excluded). Same feed the homepage globe pulse reads. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
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 adds useful details like 'trustset excluded' and 'Wrapped in the proof envelope', which are meaningful behavioral traits. However, it does not disclose whether this is a read-only operation, any authentication requirements, rate limits, or how the proof envelope affects the response. The description is informative but 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences, each serving a distinct purpose (data scope, source context, proof envelope). It is front-loaded with the core action and adds no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description is reasonably complete. It explains what is returned, the data scope, exclusions, and a notable behavioral trait (proof envelope). However, it does not describe the exact return format or pagination behavior, and it does not explicitly differentiate from sibling tools, leaving minor gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents a 'limit' integer with a default of 25, and schema coverage is 0%. The description adds semantic meaning by interpreting it as 'the last N' events, clarifying that limit controls the count returned. This directly helps the agent understand the parameter's role, though it does not mention any minimum, maximum, or validation constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Return') and resource ('whale events'), then adds scope details: 'XRP-denominated', 'tagged-watchlist', and 'trustset excluded'. It also references the homepage globe pulse feed, which distinguishes it from sibling tools like get_whale_watchlist by showing it provides a combined event feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'Same feed the homepage globe pulse reads', which tells the agent this is the source for a specific UI element. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_whale_watchlist) or provide any exclusion criteria. The usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_whale_watchlistAInspectReturn the last N tagged-watchlist events (type='tagged'), floored at TAGGED_XRP_FLOOR_DROPS for XRP-denominated rows. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
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 meaningful behaviors: the type filter, the floor applied to XRP-denominated rows, and the proof envelope return wrapping. However, it omits details like pagination, rate limits, and whether the output is exclusively XRP-denominated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first clause clearly states what is returned. Each subsequent clause adds distinct value (type filter, floor, proof envelope) with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema, no annotations), and the description covers core behavior. However, the 'proof envelope' is unexplained, and the phrase 'floored at TAGGED_XRP_FLOOR_DROPS for XRP-denominated rows' is ambiguous about whether only XRP rows are returned or if the floor applies only to them. This leaves room for misunderstanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does explain that 'N' corresponds to the 'limit' parameter ('the last N events'), but gives no further detail on bounds, default, or valid ranges. This is adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return'), the specific resource ('tagged-watchlist events'), and a key filter (type='tagged'), which distinguishes it from the sibling tool get_whale_events. The mention of the floor and proof envelope further specifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need tagged-watchlist events—but provides no explicit guidance on when not to use it or how it compares to siblings like get_whale_events. The floor threshold hints at a use case but 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.
verify_snapshot_signatureAInspectStateless verification: re-derive the leaf hash, check the Ed25519 signature against the pinned pubkey, check the audit path against the claimed chain root. Accepts full MCP envelope or bare signed payload. Wrapped in the proof envelope.
| Name | Required | Description | Default |
|---|---|---|---|
| envelope | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explicitly enumerates the verification steps (leaf hash re-derivation, Ed25519 signature check, audit path check) and mentions statelessness. It also clarifies acceptable input variants, which adds useful behavioral context beyond the schema. However, it does not describe potential failure responses or edge cases, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded 'Stateless verification' opening followed by three concrete steps and input format notes. Every sentence contributes useful information, and the entire description is brief yet informative. The final sentence about the proof envelope is slightly vague but does not waste space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cryptographic verification and the absence of annotations and output schema, the description covers the core verification logic and input flexibility well. It lacks explicit mention of return values or error conditions, but the 'proof envelope' hint provides some indication. Considering the rich sibling context and the tool's focused purpose, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the single 'envelope' parameter (0% coverage). The description compensates by explaining that the parameter can be a full MCP envelope or a bare signed payload, and mentions the proof envelope wrapper. This adds meaningful semantic information about the parameter's accepted forms, though it remains slightly ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a verification operation with specific steps: re-deriving the leaf hash, checking the Ed25519 signature, and checking the audit path. It names the exact resource (snapshot signature) and distinguishes itself from the sibling get_* tools, which are all retrieval operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is a stateless verification and noting it accepts two input formats. It implies usage after acquiring a signed snapshot, though it does not explicitly name alternatives or state when not to use it. This is clear context without exclusions, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!