XRPL token rug-checks, issuer reputation & AMM data for AI agents. Pay-per-call USDC via x402.
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 20 of 20 tools scored. Lowest: 2.2/5.
Each tool targets a distinct resource and action: address checks, token checks, price analysis, transaction simulation, path finding, wallet history, pool discovery, attestation, and monitoring all have clear boundaries. While some tools share domain (e.g., check_xrpl_token vs resolve_asset), their purposes are clearly differentiated in descriptions.
Nearly all tools follow a verb_noun pattern (check_*, get_*, verify_*, analyze_*, explore_*, find_*, quote_*, watch_*, submit_*). The only slight deviation is 'token_holders', a noun phrase, but it is still concise and follows the same lowercase snake_case style, so it does not create confusion.
20 tools is on the heavier side of the ideal range, but the server's scope—cross-chain security, token analysis, monitoring, attestation, and market data—justifies this breadth. Each tool covers a distinct sub-domain, so the count is reasonable though slightly above the typical 3-15 sweet spot.
The tool surface comprehensively covers the domain: token discovery, safety, identity, price, holders, monitoring, address/issuer risk, transaction simulation, route finding, wallet activity, endpoint trust, and attestation. There are no obvious dead ends; users can discover tokens, verify them, track them, and receive alerts—a full lifecycle for crypto risk assessment.
analyze_token_trendAInspectA data-driven technical read on an XRPL token. Computes real indicators from OHLC — trend (9/21 EMA), RSI momentum, support/resistance, volatility, volume trend — with a plain-language assessment, and (when the server has an LLM configured) an AI-written outlook plus a genuine counter-argument. interval is 5|15|60|240|D|W, bars how many candles. Returns ai_available so you know whether the narrative is live. Always an informational signal, NEVER financial advice or a price target. Price: $0.020 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| bars | No | ||
| issuer | Yes | ||
| currency | Yes | ||
| interval | No | D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it computes specific indicators, conditionally includes AI-written outlook based on LLM configuration, returns ai_available to indicate live narrative, and charges a fee. This goes beyond typical transparency and could not be inferred from annotations or 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 dense but every sentence serves a purpose: purpose, indicators, AI condition, parameter explanation, disclaimers, price, and feedback alternative. It is slightly long but well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description enumerates the result components (indicators, plain-language assessment, AI outlook, counter-argument, ai_available). It also provides pricing, feedback path, and risk disclaimers, making it sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the interval values (5|15|60|240|D|W) and what bars means (number of candles). Issuer and currency are not explicitly detailed but are self-explanatory for an XRPL token context, so the description adds meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a technical analysis of an XRPL token, listing specific indicators (EMA, RSI, support/resistance) and explicitly distinguishing it from raw data tools like get_token_ohlc. The verb 'analyze' plus the target 'token trend' are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool provides an 'informational signal' and includes a disclaimer against financial advice, implying appropriate usage. It does not explicitly compare with alternatives like get_token_ohlc or check_xrpl_token, but the context is clear enough. A brief 'when to use this vs. others' would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_addressAInspectCross-chain address & counterparty risk — one call before you send to, approve, or trust an address. EVM chains (ethereum, base, bsc, polygon, arbitrum, optimism, avalanche, …): sanctions, mixer, phishing, drainer, money-laundering & cybercrime flags aggregated from GoPlus, told whether it's a contract or a wallet. XRP Ledger (r-addresses): Cerberus's own engine — the production rug blocklist, live clawback/global-freeze flags (can this address seize or freeze tokens it issues?), burn-address detection, and prior launch history — coverage no incumbent offers. Chain is auto-detected; pass chain to pick the EVM network (default ethereum). Verdict: high_risk | caution | safe | unknown, source named. Price: $0.008 USDC. Missing something? Call submit_feedback (free) to request it. Pass attest=true to also get an Ed25519-SIGNED attestation of this verdict — portable proof you can log, hand to a counterparty, or verify later with verify_attestation (free) or the published key.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| attest | No | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the risk sources (GoPlus, Cerberus), auto-detection of chain, verdict levels, pricing, and attestation option. No side effects or contradictions noted.
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 lengthier but every sentence provides value. It is front-loaded with the main purpose and follows a logical structure. Minor redundancy could be trimmed, but overall it's well-organized.
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's complexity (cross-chain, two engines, optional attestation, pricing), the description is remarkably complete. It covers coverage, verdicts, price, feedback option, and even missing output schema by listing verdict values and source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates. It explains the 'chain' parameter (optional, auto-detected, default ethereum), 'attest' (boolean for attestation), and 'address' (required). The explanations add meaning beyond the schema's property names.
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 purpose: 'Cross-chain address & counterparty risk — one call before you send to, approve, or trust an address.' It specifies supported chains and risk categories, distinguishing it from siblings like check_alerts or check_issuer_reputation.
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 explicitly tells when to use the tool ('before you send to, approve, or trust an address') and provides context for EVM and XRP Ledger. It does not explicitly mention when not to use it or list alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_alertsAInspectCollect alerts raised by your watch_token watches: what changed, how severe (critical | warning | info), and the on-chain numbers behind it — plus the status of every watch you own. Requires the subscriber_key from watch_token. Each alert is delivered once. FREE — poll it as often as every couple of minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| subscriber_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that alerts are delivered once and describes the data returned. It implicitly indicates a read-only operation with no side effects and mentions free usage.
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 at two sentences, front-loading the core purpose. It could be slightly more structured (e.g., separating prerequisites from behavior) but remains 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?
Given no output schema, the description provides a good overview of returned data (changes, severity, numbers, watch status). It is complete enough for a polling tool, though missing details on pagination or error handling.
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%, meaning the description adds minimal value for parameters. It mentions subscriber_key in the description but does not explain its role or the limit parameter. This is insufficient for an agent to correctly invoke the tool.
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 collects alerts from watch_token watches, detailing what is included (changes, severity, on-chain numbers, status of watches). It distinguishes itself from sibling tools like watch_token which creates watches, and other check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the prerequisite (subscriber_key from watch_token) and explicitly says it is FREE to poll frequently ('every couple of minutes'). However, it does not provide guidance on when to use this tool versus alternatives like check_transaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_endpointAInspectEndpoint & tool trust — one call before an agent connects to a third-party MCP server or HTTP tool. Pass the endpoint url (and, to unlock the strongest check, its tools: the name/description/inputSchema the agent is about to trust). Returns three signals behind one verdict: (1) transport & TLS identity — encrypted, valid chain, not expired or self-signed; (2) domain age via RDAP — freshly-registered hosts are a scam tell; (3) a TOOL-POISONING scan of the tool definitions for the hidden directives that hijack agents — instruction overrides, 'don't tell the user', data exfiltration, secret harvesting, tool-shadowing, and invisible-unicode / homoglyph steganography that a human reviewer can't see. Nobody else screens tool descriptions for injection. Verdict: trusted | caution | untrusted | unknown, with per-finding evidence. Price: $0.008 USDC. Missing something? Call submit_feedback (free) to request it. Pass attest=true to also get an Ed25519-SIGNED attestation of this verdict — portable proof you can log, hand to a counterparty, or verify later with verify_attestation (free) or the published key.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| tools | No | ||
| attest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: returns three signals (transport/TLS, domain age, tool-poisoning scan), pricing ($0.008 USDC), optional attest parameter for signed output, and verdict types. No contradictions.
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 lengthy but each sentence adds value, is well-organized with front-loaded purpose and subsequent details. Slightly verbose but appropriate for the complexity.
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, description explains return values (verdict with evidence). Covers parameters, pricing, attestation, and points to 'submit_feedback' for gaps. Complete for a security checking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description adds crucial meaning: 'url' is the endpoint, 'tools' are tool definitions to enable strongest check, 'attest' boolean for signed attestation. Explains why 'tools' is optional but beneficial.
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 checks an endpoint and tool definitions for security prior to connecting to third-party MCP/HTTP tools, with specific verb 'check' and resource 'endpoint'. It distinguishes from siblings like 'check_address', 'check_transaction', etc., which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'one call before an agent connects to a third-party MCP server or HTTP tool', provides context for when to use, and mentions alternatives like 'submit_feedback' for missing features and 'verify_attestation' for attestation verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_issuer_reputationAInspectReputation for an XRPL issuer: blocklist status + historical detection outcomes. Price: $0.002 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description needs to disclose behavioral traits. It reveals the cost and the action to take if missing something, but does not mention side effects, authentication needs, rate limits, or error handling. The cost disclosure is valuable, but more detail on behavior would improve transparency.
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 purpose and output, followed by pricing and an alternative action. Every sentence adds value with no wasted words. It is 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?
Given the low parameter count and no output schema, the description covers the core functionality and cost but lacks details on the parameter format and potential response structure. It is adequate but leaves some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter details in the schema beyond the name 'issuer', the description should clarify what constitutes a valid issuer (e.g., wallet address, domain). It only says 'XRPL issuer', which is insufficient for precise parameter understanding.
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 checks reputation for an XRPL issuer, returning blocklist status and historical detection outcomes. This is a specific verb+resource combination and distinguishes it from sibling tools like check_address or check_transaction.
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 mentions a price ($0.002 USDC) and suggests using submit_feedback if something is missing, providing clear context on when to use this tool and an alternative action. However, it does not explicitly list prerequisites or comparisons to other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_transactionAInspectSimulate an unsigned XRPL transaction and tell you what it will ACTUALLY do — before you sign it. Pass the transaction JSON; get back (1) its intent in plain language, (2) a live-ledger dry-run (simulate): would it succeed, and the exact balance changes per account — computed, never submitted, never signed — and (3) drain vectors flagged: handing over your signing key (SetRegularKey / SignerListSet), disabling your master key, enabling clawback, partial-payment tricks, trustlines to blocklisted issuers, sends to flagged addresses. Verdict: danger | caution | safe | unknown. A transaction that would fail on-chain is reported as such. Price: $0.010 USDC. Missing something? Call submit_feedback (free) to request it. Pass attest=true to also get an Ed25519-SIGNED attestation of this verdict — portable proof you can log, hand to a counterparty, or verify later with verify_attestation (free) or the published key.
| Name | Required | Description | Default |
|---|---|---|---|
| attest | No | ||
| account | No | ||
| transaction | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It explains the tool simulates (never submits or signs), computes results live, reports failure, and costs $0.010 USDC. It also notes optional attestation. No contradictions with annotations (none provided).
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 long but front-loaded with the main purpose and outputs. Every sentence adds value (pricing, attestation, feedback path). It is well-structured with natural breaks between functionality, pricing, and next steps. Could be slightly more concise but effectively communicates.
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's complexity (simulation, multiple outputs, pricing, attestation), the description covers nearly all aspects: how it works, what it returns, cost, and pointers to related tools. No output schema exists, so the description adequately explains return values. Sibling tools are listed for 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?
Schema description coverage is 0%, so the description must compensate. It explains 'transaction' (pass JSON) and 'attest' (get signed attestation) but does not explicitly clarify the 'account' parameter. The description is rich enough for inference but lacks direct param documentation for all 3 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 states the tool simulates an unsigned XRPL transaction and reveals its actual effects before signing. It specifies the resource (unsigned transaction) and the outputs (intent, dry-run, drain vectors, verdict), distinguishing it from sibling tools like check_address or check_alerts.
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 explicitly says to use this tool before signing a transaction to understand its impact. It hints at alternatives by directing missing features to submit_feedback and mentioning verify_attestation for attestation verification. It lacks explicit when-not-to-use guidance but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_xrpl_tokenAInspectLive safety verdict for an XRPL token: clawback & global-freeze hard rejects, issuer blackhole status (can supply ever be re-minted?), NoFreeze, pool depth & trading fee, LP-burn fraction (is liquidity locked?), plus Cerberus's proprietary rug blocklist & detection history. Verdicts: unsafe | caution | likely_safe | unknown, with reasons. currency may be a 3-char or 40-char hex code. Price: $0.005 USDC. Missing something? Call submit_feedback (free) to request it. Pass attest=true to also get an Ed25519-SIGNED attestation of this verdict — portable proof you can log, hand to a counterparty, or verify later with verify_attestation (free) or the published key.
| Name | Required | Description | Default |
|---|---|---|---|
| attest | No | ||
| issuer | Yes | ||
| currency | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses multiple behavioral aspects: live verdict, specific checks (clawback, freeze, blackhole, etc.), verdict categories, attestation signing, price, and currency format. No annotations exist, so description carries full burden; it does well but omits rate limits or auth requirements.
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 reasonably concise for the information density, front-loading the primary purpose. Every sentence adds value, though slight restructuring (e.g., grouping cost and feedback) could improve scannability.
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?
Without an output schema, the description explains return values (verdict categories with reasons) and mentions attestation output. It also covers cost, feedback mechanism, and attest option, making it fairly complete for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning: clarifies 'currency' can be 3-char or 40-char hex, explains 'attest' boolean and its effect. 'issuer' is not further detailed, but context implies it's the token issuer address. Overall, the description compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Live safety verdict for an XRPL token') and clearly distinguishes itself from siblings like 'check_issuer_reputation' (reputation vs safety) and 'verify_attestation' (verification vs generation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions cost ($0.005 USDC), alternative paths (submit_feedback for missing features, verify_attestation for verification), and the optional attest parameter. However, it does not directly contrast with all sibling tools (e.g., check_address, check_transaction).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_tokensAInspectDiscover XRPL tokens — a DexScreener-style feed over 160k+ tokens. Rank by sort (volume_24h | marketcap | holders | trustlines | price), query to search by name, limit/offset to page, trust_only for XRPLMeta-trusted only. Each row returns name, icon, USD price, 24h volume, market cap, holder count, XRPLMeta trust level, AND our rug-blocklist flag — discovery with a trust signal built in. Run check_xrpl_token on any row for the full verdict. Price: $0.004 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | volume_24h | |
| limit | No | ||
| query | No | ||
| offset | No | ||
| trust_only | 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 the read-only nature (a feed), the fields returned (including a rug-blocklist flag), and the cost ($0.004 USDC). It could go deeper on rate limits or the exact rug-blocklist algorithm, but it adds meaningful behavioral context beyond just 'explore tokens'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, followed by concise parameter semantics, and closes with price and feedback short-hook. It is slightly verbose with promotional phrasing ('discovery with a trust signal built in'), but every sentence contributes useful information and the structure is easy to scan.
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 annotations and output schema, the description is remarkably complete: it specifies tool function, all parameters with allowed values, the exact fields in each row, the pricing model, and follow-up actions (check_xrpl_token, submit_feedback). An agent has enough context to decide when to call this tool and how to construct a proper request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does: sort values are enumerated, query searches by name, limit/offset page, and trust_only filters to XRPLMeta-verified tokens. This adds far more than the schema alone, which lacks enum definitions or descriptions.
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 'Discover XRPL tokens' — a clear verb and resource — and distinguishes itself from sibling tools like check_xrpl_token by framing itself as a broad feed ('DexScreener-style over 160k+ tokens'). This makes it obvious what the tool does and how it differs from more targeted tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: sorting options, search by query, pagination with limit/offset, and the trust_only filter. It also points to alternatives (check_xrpl_token for full verdict, submit_feedback for missing features). However, it does not explicitly state when NOT to use this tool versus alternatives, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_best_pathAInspectFind the safest EXECUTABLE route to acquire an XRPL token and screen every hop. Unlike quote_amm (one direct AMM pool), this asks the ledger for real payment paths (order books + AMM + multi-hop) and runs the rug-safety engine over every issuer and gateway the route touches — a clean token reached through a hop that can freeze or claw back mid-route is a trap a destination-only check misses. Returns the cheapest route, its effective price, hop count, and a verdict: route_safe | route_caution | route_unsafe | no_route, with the risk on each hop. Pass your account for routes specific to your trustlines, or omit it for an indicative route. Price: $0.006 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| to_amount | No | ||
| to_issuer | Yes | ||
| from_issuer | No | ||
| to_currency | Yes | ||
| from_currency | No | XRP |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden and exceeds expectations: discloses return format (cheapest route, price, hop count, verdict and per-hop risk), pricing ($0.006), and screening behavior (checks each issuer/gateway for freeze/clawback). No contradiction or omission.
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?
Information-dense but well-structured: front-loads purpose, then differentiation, then details, then price. Each sentence adds value. Slightly long but efficient for the complexity covered.
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 6 parameters, no output schema, and no annotations, description covers all major aspects: route discovery, safety screening, return values, pricing, and alternative (submit_feedback). Fully sufficient for a query tool with many siblings.
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?
0% schema coverage means description must compensate. It explains account (optional for indicative vs trustline-specific) and implicitly covers to_currency/to_issuer via 'acquire an XRPL token'. Does not detail from_issuer, to_amount, or from_currency default (only shown in schema). Some gaps remain.
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?
Description uses specific verb 'Find' and resource 'safest EXECUTABLE route' to acquire an XRPL token, clearly distinguishing it from sibling quote_amm (one direct AMM pool). It explains the ledger query and rug-safety engine, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with quote_amm, guiding when to choose this tool (multi-hop route with safety screening). Advises passing account for trustline-specific routes or omitting for indicative route. Does not list exclusions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_new_poolsBInspectRecently detected XRPL AMM pools (newest first, max 100), enriched: readable name, age, initial liquidity and fee, plus an honest launch-time screening label. Price: $0.010 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does disclose pricing ($0.010 USDC), result size limits ('max 100'), sorting ('newest first'), and enrichment fields. However, it does not explain the nature of the 'honest launch-time screening label,' potential errors, or whether results are cached/snapshot-based. Some key behaviors remain opaque.
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 concise sentences, front-loaded with the core purpose and key data attributes. Every sentence earns its place: the first covers purpose, ordering, limit, and richness; the second covers pricing and feedback path. No wasted words.
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's simplicity (one optional parameter, no output schema), the description provides a solid overview of returned content, ordering, and constraints. It mentions a price and a fallback feedback mechanism. It is not fully exhaustive (e.g., no explicit field types or example response), but adequate for a list-retrieval tool without an output schema.
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 input schema has a single 'limit' integer with a default of 20 and 0% description coverage. The description does not explain this parameter at all, only mentions a global 'max 100' cap. The parameter name and default hint at meaning, but the description adds no semantic value beyond the schema itself.
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 returning 'Recently detected XRPL AMM pools' with specific enrichment details (readable name, age, initial liquidity, fee, screening label). It includes ordering ('newest first') and a limit ('max 100'), giving concrete scope. It does not explicitly contrast with sibling tools, but the resource and action are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you want newly detected XRPL AMM pools, with a clear ordering and maximum. However, there are no explicit when-to-use or when-not-to-use instructions, nor alternatives mentioned aside from a generic 'submit_feedback' call. The guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_token_ohlcAInspectOHLC price-history candles for an XRPL token — open/high/low/close plus volume per interval, the series behind a candlestick chart. interval is 5 | 15 | 60 | 240 | D | W (minutes, or Day/Week); bars is how many candles (max 1000); prices are quoted in XRP, or pass fx="USD" for USD. Sourced from the XRPL DEX/AMM; returns ok:false with a reason when the pair is unknown or the source is unreachable — never invented prices. Price: $0.004 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| fx | No | ||
| bars | No | ||
| issuer | Yes | ||
| currency | Yes | ||
| interval | No | 60 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it discloses the data source (XRPL DEX/AMM), error behavior (ok:false with reason when pair unknown/unreachable), data integrity (never invented prices), cost, and parameter constraints. This is exceptionally 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 concise and front-loaded with the core definition, then parameter details, source, and error behavior. The cost and feedback call-to-action are useful context but not strictly necessary for tool invocation, so it is slightly less tight than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate parameter complexity, the description covers purpose, parameter syntax, data source, error behavior, and pricing. It leaves the successful return envelope implicit but adequate; a bit more detail on the exact response structure would make it a 5.
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%, so the description compensates well by explaining interval (5|15|60|240|D|W), bars (max 1000), and fx ('USD'). Issuer and currency are inherently clear from the XRPL token context, though not explicitly detailed, which keeps this from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing OHLC price-history candles for an XRPL token, specifying open/high/low/close and volume per interval. This directly distinguishes it from sibling tools like verify_price (price verification) and check_xrpl_token (token metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context that this is for historical price data behind candlestick charts and explains parameter usage (interval, bars, fx). However, it does not explicitly mention when not to use it or name alternative tools, so it misses the full bar for explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_activityAInspectA readable, risk-annotated history of what an XRPL wallet did: recent transactions turned into plain language (sent/received amounts with token names, trustlines, DEX/AMM ops), with counterparties on the Cerberus rug blocklist flagged, new trustlines to blocklisted issuers flagged, and account-takeover transactions (SetRegularKey, SignerListSet, master-key disable) surfaced as notable — watching your OWN wallet is compromise detection. Returns XRP balance, a summary (in/out counts, distinct and flagged counterparties, notable events), and a marker to page further back. Read-only. Price: $0.008 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it is read-only, flags blocklisted counterparties, surfaces notable transactions, and returns specific data including a pagination marker. It also mentions the price and a feedback channel. This exceeds the burden for transparency, clearly stating the tool's safety and functional traits.
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 long sentence followed by a short feedback note. It is dense with valuable information and front-loaded with the core purpose, but the length and run-on structure slightly reduce readability. Every sentence earns its place, though the first sentence could be more scannable.
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 covers purpose, return values (balance, summary, marker), risk features, price, and read-only nature. With no output schema, it reasonably explains outputs. However, it lacks details on error conditions, exact formatting of returned data, or how pagination actually works (e.g., using a recent call's marker as input), leaving minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It mentions 'address' indirectly via 'wallet' and 'recent transactions' but does not clarify the 'limit' parameter or any pagination input. The marker is only described as a return value, not as an input for further paging. This leaves significant gaps for the two 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 states the tool's purpose: providing a readable, risk-annotated history of an XRPL wallet's recent transactions. It lists specific features (plain-language amounts, trustlines, DEX/AMM ops, blocklist flags, notable account-takeover transactions) and distinguishes itself from sibling tools like check_address or check_alerts by focusing on comprehensive wallet activity monitoring.
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 a clear use case ('watching your OWN wallet is compromise detection') and notes it is read-only and priced. However, it doesn't explicitly contrast with sibling tools or state when not to use it, instead deferring unmet needs to submit_feedback. This provides context but lacks explicit exclusions or direct alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_ammCInspectQuote an XRP->token swap against the live XLS-30 AMM pool: tokens out, spot vs effective price, price impact. Price: $0.001 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer | Yes | ||
| xrp_in | No | ||
| currency | Yes |
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 only mentions what the tool returns but does not state whether the operation is read-only, if it requires authentication, rate limits, or any side effects. This is a significant gap for a tool that queries an AMM pool.
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 short with two meaningful sentences, but the inclusion of 'Price: $0.001 USDC' seems like an example or placeholder that adds confusion rather than value. It is concise but the structure is slightly muddled by the extraneous price line and the feedback suggestion.
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 3 required parameters, no output schema, and no annotations, the description is woefully incomplete. It lacks parameter explanations, return value format, example usage, or any guidance on prerequisites. An agent would struggle to correctly invoke this tool without additional 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 input schema has 3 parameters (issuer, xrp_in, currency) with 0% description coverage. The description does not explain any parameter in detail. It vaguely implies that xrp_in and currency relate to the swap but does not clarify the 'issuer' parameter, leaving the agent without necessary guidance for correct usage.
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 (quote), the resource (XRP->token swap via XLS-30 AMM pool), and what is returned (tokens out, spot vs effective price, price impact). The mention of a specific price ($0.001 USDC) is confusing and detracts slightly, but the core purpose is still clear. It also distinguishes from sibling tools like find_best_path by specifying a direct pool quote.
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 includes 'Missing something? Call submit_feedback (free) to request it,' which gives a hint for when to use a sibling tool for feedback but provides no guidance on when to use this tool versus alternatives like find_best_path. There is no explicit when-to-use or when-not-to-use advice, leaving the agent uncertain about choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_assetAInspectCross-chain identity for an XRPL token — 'what is this, everywhere it exists?' Resolves the token's real identity across chains and catches IMPOSTORS: a token using a famous symbol (USDC, WBTC, SOLO…) from an issuer that is NOT that asset's canonical deployment is flagged — a fake USDC is a fake USDC on every chain, and a single-chain check misses it. Combines XRPLMeta (the XRPL registry: name, issuer, trust_level), CoinGecko (the canonical multi-chain asset and every chain it lives on), and Cerberus's rug blocklist. Verdict: verified_crosschain | native_xrpl | impostor_suspected | unverified | unknown. Price: $0.008 USDC. Missing something? Call submit_feedback (free) to request it. Pass attest=true to also get an Ed25519-SIGNED attestation of this verdict — portable proof you can log, hand to a counterparty, or verify later with verify_attestation (free) or the published key.
| Name | Required | Description | Default |
|---|---|---|---|
| attest | No | ||
| issuer | Yes | ||
| currency | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it combines XRPLMeta, CoinGecko, and Cerberus data, costs $0.008, returns verdicts, and supports attestation. It also warns about impostor detection, providing a complete safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and adds details on sources, verdicts, cost, and attestation. Each sentence adds value, though it is slightly verbose. It is well-structured for an agent to parse quickly.
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 all essential aspects: input parameters, data sources, possible verdicts, cost, attestation feature, and feedback channel. It is complete for an agent to understand and invoke the tool 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?
Schema coverage is 0%, so the description must compensate. It mentions 'issuer' and 'currency' implicitly but does not clarify their format (e.g., XRPL address, hex currency code). The 'attest' boolean is explained briefly. Some semantic gaps remain, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: resolving a token's cross-chain identity on XRPL, detecting impostors using multiple sources. It uses a specific verb ('resolve') and resource ('asset'), and distinguishes itself from siblings like 'check_xrpl_token' by emphasizing multi-chain 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 this tool (for cross-chain identity checks) and mentions alternatives like 'submit_feedback' for missing assets. It does not explicitly state when not to use it, but the context is clear for an AI agent to differentiate from single-chain tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackAInspectRequest a tool/feature or report an issue. FREE. High-volume requests get built first — this is how you shape Cerberus's roadmap.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | ||
| message | Yes | ||
| requested_capability | No |
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 only states it's 'FREE' but does not disclose any side effects, return behavior, or whether feedback is stored/sent. Significant gaps.
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 purpose, no wasted words. Efficient and to the point.
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?
Tool is simple, but description lacks parameter explanations and post-submission behavior. For a feedback tool, users need to know what happens after submission. Incomplete given no output schema.
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 has 3 parameters with 0% description coverage. Description only mentions 'tool/feature' and 'issue', leaving the 'tool' parameter unexplained. No format or constraints provided.
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?
Description clearly states the tool's purpose: 'Request a tool/feature or report an issue.' It uses specific verbs and resources, and distinguishes from sibling tools (all check/verify tools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context ('FREE. High-volume requests get built first') and implies usage for shaping the roadmap. No direct alternative is needed since no sibling tool overlaps in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
token_holdersAInspectHolder distribution & concentration risk for an XRPL token: holder count, top-1 and top-10 share of circulating supply, AMM pool excluded from whale math. Flags single-wallet dump risk. Best for newer tokens (large tokens report 'unknown_large' honestly rather than guessing). Price: $0.008 USDC. Missing something? Call submit_feedback (free) to request it.
| 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. It discloses key behaviors: AMM pools are excluded from whale math, and the tool flags single-wallet dump risk. It also honestly reports 'unknown_large' for large tokens. It does not state if the tool is read-only, but the context implies it is a query 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 concise, with front-loaded key purpose and metrics. Every sentence adds value—purpose, scope, behavior, pricing, and feedback suggestion. No unnecessary words.
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 mentions the output contains holder count, shares, and risk flags, but does not specify the exact response structure or whether pagination exists. Given no output schema, some return value details would improve completeness, but the core purpose is adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. While it mentions 'issuer' and 'currency' implicitly as XRPL token identifiers, it does not explicitly define acceptable formats (e.g., issuer address, currency code) or provide examples. This lack of specificity could confuse an AI agent unfamiliar with XRPL.
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 holder distribution and concentration risk for an XRPL token, specifying metrics like holder count, top-1 and top-10 share, and AMM pool exclusion. It also distinguishes behavior for new vs. large tokens, making the purpose very specific and actionable.
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 indicates the tool is 'Best for newer tokens' and explains that for large tokens it reports 'unknown_large' honestly, providing guidance on when it's most useful. However, it does not explicitly mention when not to use it or compare to sibling tools like check_xrpl_token or resolve_asset, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_attestationAInspectVerify a signed Cerberus attestation (from any tool called with attest=true). Recomputes the canonical claim and checks the Ed25519 signature against this server's published key. Returns valid true/false with the claim. FREE — and you can verify independently with the public key at /api/attestation; this is a convenience, not a trust bottleneck.
| Name | Required | Description | Default |
|---|---|---|---|
| attestation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the verification process: recomputes claim, checks Ed25519 signature, returns valid flag and claim. It also notes the tool is free. No side effects are mentioned, but they are likely none. Lacks error handling details but sufficient for this 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 two sentences with no fluff. It is front-loaded with the main action and efficiently adds context about independence and free-ness. 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 no output schema and no schema coverage, the description explains input provenance, process, and output. However, it does not specify the claim structure or exact parameter fields, which may require the agent to infer from other tools. Still reasonably complete for the tool's purpose.
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 structure or format of the attestation object beyond 'from any tool called with attest=true'. The parameter is essentially opaque, relying on prior knowledge of other tool outputs.
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 verb 'Verify' and the resource 'signed Cerberus attestation'. It distinguishes from sibling tools by specifying it handles attestations from tools called with attest=true, which is unique among the sibling 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 says when to use it: to verify attestations from other tools. It also mentions that independent verification is possible, implying this tool is optional. However, it does not explicitly state when not to use it or provide comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_issuer_domainAInspectBidirectional domain verification for an XRPL issuer: decodes the on-chain Domain field and checks the domain's /.well-known/xrp-ledger.toml actually claims the issuer back. verified true/false with reasons — a strong legitimacy signal (its absence is a yellow flag). Price: $0.003 USDC. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the bidirectional process, output (verified true/false with reasons), and price/cost context. However, it lacks details on error handling, rate limits, auth requirements, or side effects, leaving gaps for a non-trivial 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?
Three sentences with no fluff. First sentence explains core functionality, second adds output and significance, third mentions price and feedback. Could be slightly more focused but efficient overall.
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 low complexity (1 parameter, no output schema), description covers purpose, process, output format, and pricing. Missing input format details and error conditions, but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but only adds 'for an XRPL issuer'. It does not specify format (e.g., r-address), provide examples, or clarify constraints beyond naming. Minimal added value over the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'bidirectional domain verification for an XRPL issuer' with specific steps: decoding on-chain Domain field and checking .well-known file. It distinguishes from sibling tools like check_issuer_reputation by focusing on domain linkage verification.
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 for verifying domain legitimacy ('a strong legitimacy signal, absence is a yellow flag') but does not explicitly explain when to use this tool versus alternatives like check_issuer_reputation or verify_attestation. No when-not or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_priceAInspectCross-chain value truth for an XRPL token — 'is the price real?' Reconstructs the token's USD price on XRPL (XRPLMeta price × live XRP/USD) and checks it two ways: for a stablecoin, whether the PEG still holds (is USDC actually ~$1 here?); for any cross-chain asset, whether the XRPL price has DIVERGED from its canonical price elsewhere (manipulation, stale liquidity, or arbitrage). Weighs it against real 24h volume — a price on a dead pool is a number, not a market. Verdict: price_consistent | price_divergent | depegged | thin_liquidity | native_no_reference | unknown. Price: $0.008 USDC. Missing something? Call submit_feedback (free) to request it. Pass attest=true to also get an Ed25519-SIGNED attestation of this verdict — portable proof you can log, hand to a counterparty, or verify later with verify_attestation (free) or the published key.
| Name | Required | Description | Default |
|---|---|---|---|
| attest | No | ||
| issuer | Yes | ||
| currency | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the verification process (reconstructing USD price, checking peg, divergence, volume) and discloses optional signed attestation. It does not mention error handling or authorization, but provides substantial behavioral insight.
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 well-structured and front-loaded with the core question. It is informative but could be slightly more concise by removing the example price line. Overall, each 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 no output schema, the description adequately explains return values (verdict types, price, optional attestation). It covers required inputs and behavior but lacks details on error conditions or missing tokens.
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%, so the description must compensate. It explains the attest parameter well but does not explicitly define issuer and currency, though context implies they identify the token. The description adds value for attest but is insufficient for required 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 states the tool's purpose: cross-chain value truth for an XRPL token, checking if a price is real. It uses specific verbs (reconstructs, checks, weighs) and distinguishes from sibling tools like check_xrpl_token by focusing on price verification.
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 explains when to use the tool (for stablecoins, cross-chain assets) and mentions alternatives like submit_feedback for missing features. However, it does not explicitly state when not to use it or contrast with related tools such as check_xrpl_token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_tokenAInspectMonitor an XRPL token you hold and get alerted when it turns dangerous. A one-time check can't catch a rug that happens later — this watches the chain continuously for: AMM pool destroyed (completed rug), liquidity drained past your threshold, clawback enabled, global freeze set, issuer un-blackholed (supply re-mintable), issuer blocklisted, LP lock weakened. Returns a subscriber_key — STORE IT — then poll check_alerts (free). Registration is refused (with the reason) for tokens that are ALREADY compromised — blocklisted, clawback-enabled, frozen, or a husk pool — since those need a verdict now, not monitoring later. Sold as packages by monitoring window (duration_days): 1d $0.005 · 3d $0.012 · 7d $0.020 · 14d $0.035 · 21d $0.048 · 30d $0.060 USDC (longer = cheaper per day). The x402 payment demand lists every tier; pay the one you want and the watch length is set by what you pay. Calling again renews (extends) the watch. Missing something? Call submit_feedback (free) to request it.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer | Yes | ||
| currency | Yes | ||
| rebaseline | No | ||
| duration_days | No | ||
| subscriber_key | No | ||
| drain_threshold_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses many behaviors: monitored conditions, refusal for already compromised tokens, pricing packages, renewal on calling again, and return of subscriber_key. It is mostly transparent but could clarify the x402 payment flow and that the tool costs money.
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 somewhat long but every sentence adds value. It is front-loaded with the main purpose and then details. Minor redundancy could be trimmed, but overall well-structured.
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 6 parameters, no output schema, and no annotations, the description covers the tool's behavior, return value, pricing, limitations, and lifecycle (e.g., renewal). It mentions related tools. It is fairly complete, though the rebaseline parameter is unaddressed and the payment mechanism could be clearer.
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%, so description must add meaning. It explains issuer, currency, duration_days (via package listing), drain_threshold_pct (via 'liquidity drained past your threshold'), and subscriber_key (used for renewal). However, the 'rebaseline' parameter is not mentioned, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool monitors an XRPL token continuously for dangerous conditions, listing specific events. It differentiates from sibling tools like check_xrpl_token which does a one-time check, and mentions alternative tools like check_alerts and submit_feedback.
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 explains when to use (holding a token needing continuous monitoring), when registration is refused (already compromised tokens), and what to do after (store subscriber_key, poll check_alerts). It could be more explicit about when to use sibling tools like check_xrpl_token as an alternative.
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!