XRP Ledger Testnet MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have nearly identical purposes, such as send_token vs transfer_token, get_wallet_info vs get_account_info, get_chain_info vs get_network_info, and get_gas_price vs estimate_fees. Even with descriptions, these overlaps make it difficult for an agent to reliably pick the right tool.
Naming Consistency5/5
All tool names follow the same xrp_ prefix with snake_case and a consistent verb_noun structure (e.g., xrp_create_escrow, xrp_finish_escrow, xrp_cancel_escrow). No mixing of conventions, making the naming highly predictable.
Tool Count2/5
With 51 tools, the server is overstuffed. Many tools are redundant variants of the same operation (e.g., send_token/transfer_token, mint_nft/mint_nft_with_ipfs), inflating the count without adding genuine functionality. A leaner set would be more effective.
Completeness3/5
The toolset covers major XRP Ledger areas (wallets, transactions, escrow, DEX, NFTs, tokens), but missing key operations like AMM creation/swapping, payment channels, and checks. The redundancy doesn't address these gaps, leaving notable holes in advanced functionality.
Average 3.1/5 across 51 of 51 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only says 'Get info,' which implies a read-only operation without confirming it. It does not describe what info is returned, whether any side effects occur, or if special permissions are needed, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified. It is structurally efficient but lacks key details, earning a mid-range score for conciseness that balances brevity and substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested object parameters, no annotations, and no output schema, yet the description provides only a vague one-liner. It does not clarify the need for both assets, the meaning of issuer/currency, or what 'info' will be returned, leaving the agent unprepared to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description entirely fails to explain that asset1 and asset2 are the two assets defining the AMM pool. The nested structure (issuer, currency) is undocumented, so the agent cannot infer valid input formats or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('AMM pool'), making it a specific verb+resource combination. However, it does not distinguish this from sibling tools like xrp_get_offers or xrp_get_ledger_entry, which also retrieve XRP-related data, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention appropriate contexts, prerequisites (e.g., the pool must exist), or any exclusions, leaving the agent without decision support for selecting this tool among many getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'Get order book depth' without revealing what data is returned (e.g., bids/asks arrays), how the currency pair parameters affect results, or any edge cases. This is minimal and does not add meaningful behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is very concise, but it is also under-specified. It does not earn its place by providing critical information beyond restating the tool's name. The sentence is too short to be helpful given the tool's complexity (nested parameters, no output schema, no annotations).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters including nested objects, no output schema, and no annotations, yet the description is only one sentence. It does not explain how to structure the currency pair objects, what 'depth' entails, or what the response contains. This is insufficient for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (limit, taker_gets, taker_pays) provided a brief description. The tool description adds no additional parameter semantics, but per the baseline for high schema coverage, a score of 3 is appropriate. The nested objects' structure is not elaborated in either the schema or the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves order book depth for a currency pair, using a specific verb ('Get') and resource ('order book depth'). It does not explicitly differentiate from the sibling tool xrp_get_offers, which could be seen as overlapping, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as xrp_get_offers or xrp_get_ledger_entry. The description lacks any context about typical use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only states the action; it doesn't mention whether it returns grouped categories, what happens when 'category' is omitted, or any read-only guarantees. The behavior is opaque beyond the basic listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately brief for a simple listing operation, though it sacrifices explanatory content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and partial parameter documentation, the description is too thin. It fails to mention the optional nature of 'category', the default behavior of 'includeDescriptions', or what the response structure looks like. This leaves the agent with significant uncertainty in invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters (category has a description, includeDescriptions does not). The tool description adds no parameter-specific detail; it only mentions 'category' generically. 'includeDescriptions' is not explained anywhere, leaving the agent to guess its effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('tools') and indicates organization by category. It distinguishes itself from sibling tools like xrp_search_tools by focusing on browsing rather than searching. However, it doesn't mention the optional category filter, so it's not fully precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus xrp_search_tools or xrp_help. The description gives no exclusions or alternative recommendations. The only implication is for browsing tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Place a buy or sell order on the DEX', omitting important details like signing requirement, on-chain side effects, order lifecycle, or fee implications. The phrase 'on the DEX' adds some context but is insufficient for a mutating trading operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is easy to scan and directly states the core action, though it sacrifices substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with nested objects, no annotations, and no output schema. The description fails to explain the key parameters, the trading semantics, or the expected outcome. It is far too minimal for an order placement operation and leaves the agent with substantial ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no explanation for taker_gets or taker_pays. These are non-obvious trading parameters that need clarification (e.g., which represents the asset being bought vs sold). The description provides zero help in understanding them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Place') and the resource ('a buy or sell order on the DEX'), which is specific enough to distinguish it from sibling tools like xrp_cancel_order or xrp_get_order_book. It conveys both the operation type and its domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer context solely from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states that the tool returns 'comprehensive' info, but gives no details about response shape, potential rate limits, costs, or what 'network status' specifically includes. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is somewhat under-specified, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what 'chain info' includes to help the agent understand return values. It fails to do so, and the overlap with 'xrp_get_network_info' leaves ambiguity about scope. The low complexity (no params) is offset by the lack of behavioral or output detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema already covers all possible inputs. The description adds no parameter-level semantics, but no additional explanation is necessary; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and identifies the resource ('XRP Ledger information'), but the qualifier 'comprehensive' is vague and does not specify what information is actually returned. The existence of a closely named sibling tool 'xrp_get_network_info' further muddies differentiation, as both seem to cover network status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus 'xrp_get_network_info', 'xrp_get_gas_price', or other information-related siblings. The description provides no context for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states what it does, but does not mention side effects (e.g., whether it creates or modifies a trustline), transaction fees, reversibility, or required permissions. As a mutation operation, these are important undisclosed behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single short sentence. It is front-loaded with the main action and object. However, the parenthetical could be more informative, but it does not waste words. Efficiency is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 4-parameter tool with no annotations and no output schema, so the description needs to provide substantial context. It fails to explain the operation flow, whether a trustline is created or updated, how the approval interacts with existing token allowances, or what the expected result is. The description is too minimal for an agent to understand the tool's place in a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds little extra meaning beyond 'trustline management' which hints at the relationship between limit and trustline. However, it doesn't clarify nuances like whether the limit represents the total allowance or per-issuer, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' with a clear object 'token spending authorization', and the parenthetical 'trustline management' provides additional context. It is distinct from siblings like xrp_get_token_allowance which reads allowance, and xrp_create_trustline which creates a trustline. However, 'trustline management' is somewhat generic, so it doesn't fully differentiate from other trustline-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool names are mentioned. The description implies a use case for setting authorization but does not clarify how it relates to siblings such as xrp_create_trustline or xrp_send_token, leaving the agent to infer when this specific tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it relies on network conditions, what output format to expect, or if it requires any prerequisites. This is insufficient for a tool carrying the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy or fluff. It is concise and directly states the tool's purpose, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description should explain more about the nature of the estimate (e.g., how it's calculated, what the return value contains). The current description leaves these important operational aspects unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a 100% description of the single parameter (transactionType), including examples. The tool description simply reiterates 'different transaction types' without adding new meaning, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Estimate transaction fees for different transaction types.' It is specific enough to distinguish from fee-related siblings like xrp_get_gas_price, though it doesn't explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of contexts, exclusions, or related tools, which is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'optional derivation paths' but does not explain what they are, whether the addresses are funded, whether private keys are returned, or whether generation is deterministic or random.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter), but the description is too sparse without annotations or an output schema. It leaves critical questions unanswered: what does the tool return (addresses? private keys?), what are 'derivation paths', and how does this relate to wallet creation or import? The presence of a sibling tool (xrp_create_wallet) makes this lack of context more harmful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the 'count' parameter with a description and default value, so the schema covers the parameters well. The description adds the concept of 'derivation paths' but does not map it to any parameter, which could confuse agents into expecting a parameter that does not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Generate new XRP addresses') and mentions a distinguishing feature ('optional derivation paths'). However, it does not differentiate this tool from the sibling xrp_create_wallet, which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like xrp_create_wallet or xrp_import_wallet. The description lacks any exclusions, prerequisites, or contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It simply states a read operation without mentioning whether results are paginated, whether the optional 'type' filter limits the 'all objects' claim, or what the response looks like. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and resource. It contains no fluff or repetition, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling tools with overlapping getter functionality, the description is too sparse to help an agent select the correct tool. It does not explain what constitutes an 'object', mention the type filter, or clarify how it differs from more specific getters. The lack of an output schema further increases the need for context that is not provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage ('Account address' and 'Filter by object type'), so the baseline is 3. The description adds minimal context by tying the purpose to an account, but it does not enhance the meaning of either parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all objects owned by an account' clearly states the verb (get), the resource (objects owned by an account), and the scope (all). It is not a tautology and provides a clear basic purpose, but it does not differentiate from more specific sibling tools like xrp_get_escrows or xrp_get_nfts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as xrp_get_escrows or xrp_get_nfts. It only implies a general use case for retrieving all account objects, but does not mention when specialized getters would be more appropriate, nor does it note any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behaviors. It does not mention that the operation is read-only, what the output contains (e.g., offer details, pagination), or any rate limits. The single line provides no behavioral transparency beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the core action, though it could be improved by adding a second sentence for context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a read tool with no output schema and no annotations, the description should clarify what is returned (e.g., list of open offers with details) but does not. It also lacks guidance on edge cases or interpretation, making it incomplete for an agent relying solely on this text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter 'address' as 'Account address' (100% coverage). The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get open offers for an account' uses a specific verb and resource, and clearly differentiates from siblings like xrp_get_order_book by scoping to an account's offers. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as xrp_get_order_book or xrp_get_account_objects. There are no exclusions or preferred contexts, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get') but does not disclose potential side effects, authentication requirements, return format, or any edge cases or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the tool's purpose without unnecessary words. It is front-loaded and contains no filler, making it an appropriate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not specify what constitutes 'token metadata' or what issuer information will be returned. Given the absence of annotations and output schema, the description is too sparse to fully prepare an agent for the tool's response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions ('Token issuer address' and 'Currency code'), so the baseline is 3. The tool description does not add any additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'token metadata and issuer information,' which clearly identifies the tool's function. It is distinguishable from sibling tools like xrp_get_token_balance and xrp_get_trustlines, though it does not explicitly compare to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other XRP getter tools such as xrp_get_token_balance or xrp_get_trustlines. There is no mention of exclusions or alternatives, leaving usage decisions entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden of behavioral disclosure. It only states the action without revealing return format, pagination behavior, ordering, whether it includes all transaction types, or any error cases. While it implies a read-only operation, it provides no additional context about the behavior beyond what the tool's name already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence: 'Get transaction history for an address.' It contains no filler, is front-loaded with the action, and is appropriately sized for a straightforward tool. Every word adds value, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a terse description, the agent has insufficient context to fully understand the tool's behavior. The description covers only the basic purpose, leaving gaps about what the history includes, response structure, limitations, and prerequisites. Given the availability of sibling tools, a more complete context would help disambiguate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (address, limit) already described in the schema. The description adds no extra meaning about parameters—it doesn't mention that limit controls the number of transactions or how address is used. Baseline 3 applies because the schema handles parameter documentation, and the description offers no clarifying semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get transaction history for an address.' It uses a specific verb ('Get') and resource ('transaction history'), which distinguishes it from sibling tools like xrp_get_transaction (singular transaction) and xrp_get_escrows. However, it doesn't elaborate on scope (e.g., incoming/outgoing, current vs. all) or explicitly differentiate among siblings, so it's clear but not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description lacks any context about when it is appropriate (e.g., 'use this to list past transactions' or 'instead of xrp_get_transaction') and doesn't mention any exclusions or prerequisites. This is a minimal one-liner with no usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states what information is returned, but does not mention read-only nature, network requirements, validation behavior, or error handling. This is minimal and leaves significant unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only one well-documented parameter, but no output schema is provided and the description does not clarify the return structure or differentiate from similar tools. The term 'comprehensive' is vague and incomplete, leaving the agent uncertain about what exact data will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'address' parameter. The description does not add any additional parameter semantics beyond what the schema states, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Get') and resource ('comprehensive wallet information') and even enumerates key fields (balance, nonce, transaction count). However, it does not distinguish this from sibling tools like xrp_get_balance or xrp_get_account_info, which likely overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the existence of xrp_get_balance, xrp_get_account_info, and xrp_get_account_objects, the absence of any selection criteria leaves the agent guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosure. It only states 'Get help and guidance' without explaining output format, whether it requires a topic, or any side effects. This is minimal for a tool that could provide various types of assistance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasteful content. It is appropriately sized for a simple help tool, though it could add more useful context without compromising conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, but the description does not explain what kind of help is provided, what topics are covered, or what the response looks like. Given the similarity to sibling tools, more context is needed to fully understand its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'topic' parameter already described as 'Help topic or tool name'. The tool description adds no additional parameter detail, so the schema does the heavy lifting. A baseline of 3 is appropriate given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Get help') and identifies the resource ('XRP MCP tools'), clearly indicating this tool provides assistance. However, it does not differentiate from similar sibling tools like xrp_search_tools or xrp_list_tools_by_category, making its exact scope somewhat generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing help but provides no explicit guidance on when to choose this tool over alternatives like xrp_search_tools. It lacks context about whether to provide a topic or how the help content is structured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Mint a new NFT' and does not mention that this is a ledger transaction, that privateKey is required and must control a funded account, that fees apply, or that minting is irreversible. This is a significant gap for a financial mutation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded with the action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that mints NFTs on a ledger, the description is incomplete: no output format (e.g., transaction hash), no failure modes, no prerequisites (e.g., funded account), and no explanation of flags/taxon semantics beyond schema. The single sentence is not sufficient for a transaction of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides 100% description coverage for all 5 parameters, so baseline is 3. The description adds no additional parameter semantics beyond the schema. The schema already explains URI, flags, taxon, privateKey, and transfer_fee meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mint a new NFT on XRP Ledger' clearly states the action (mint) and resource (NFT) with platform context. It distinguishes from siblings like xrp_burn_nft and xrp_create_nft_offer, though not explicitly from xrp_mint_nft_with_ipfs, which is inferable from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like xrp_mint_nft_with_ipfs. The description only states what it does, leaving usage context entirely implied. There are no exclusions, prerequisites, or references to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'Search available tools by keyword' without disclosing return format, search behavior (fuzzy vs exact), or any side effects. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded, with zero waste. It is appropriately minimal for a search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema and the description does not explain what the search returns (e.g., tool names, descriptions). The agent lacks information about the result format, making the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (query and limit) have descriptive text. The tool description adds 'keyword' which matches the query parameter description, but it does not enhance understanding beyond the schema. Baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches available tools by keyword, with a specific verb and resource. However, it does not explicitly distinguish itself from the sibling xrp_list_tools_by_category, so it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like xrp_list_tools_by_category, nor does it state any exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides no details such as trustline requirements, transaction fee implications, failure conditions, or whether the user needs specific permissions. It simply states the action without any deeper context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, making it highly efficient and easy to parse. It earns its place with a clear subject-verb-object structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits crucial contextual information: it does not explain what the tool returns (e.g., a transaction hash or confirmation), any prerequisites like a trustline, or how it differs from the sibling xrp_transfer_token. This is especially problematic given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description adds no additional semantic meaning beyond the parameter names and brief descriptions. The baseline of 3 applies because the schema already documents each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (send) and the object (custom token) to a recipient, making the purpose evident. However, it fails to distinguish from the sibling tool xrp_transfer_token, which likely serves a similar function, so it misses the opportunity for full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus xrp_transfer_token or other transaction tools. The presence of a similarly named sibling requires explicit differentiation, but the description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Configure account settings' without mentioning that this submits a ledger transaction, requires a private key for signing, may incur fees, or is irreversible. This lack of side-effect and safety information is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary length. The 'etc' is slightly vague and could be seen as filler, but overall it is concise and readable. It earns a 4 for efficiency, though it could be tighter by specifying exact settings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is inadequate. It fails to explain what happens when the tool is invoked, return values, error conditions, or transaction behavior. The schema covers parameter formats, but the overall operational context is missing, making the tool difficult to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds no extra meaning beyond naming 'transfer fees, flags,' which are already in the schema. Per the baseline rule, a high-coverage schema warrants a score of 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Configure') and the resource ('account settings'), with examples like 'transfer fees, flags' that hint at scope. It distinguishes from sibling tools, none of which handle account settings. However, the 'etc' is vague and lacks explicit mention of the XRP ledger context, so it is clear but not outstanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, prerequisites, or scenarios. The name and minimal description imply configuration of an XRP account, but no exclusions or alternative tool references are provided. This is effectively no guidance, giving a score of 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic transfer action. It does not disclose side effects like transaction fees, need for trustlines, potential failures, or what happens upon success. The full behavioral burden falls on the description, which is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It is front-loaded with the verb and resource, but lacks additional context or structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction tool with five required parameters, no annotations, and no output schema, the description is too sparse. It omits important context like how to obtain the privateKey, what constitutes a valid issuer, amount formatting, and expected behavior on success or error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no extra semantic value beyond the schema, such as format constraints or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (transfer), the resource (custom tokens), and the parties (between accounts). It distinguishes from similar tools like xrp_send_token by specifying 'custom tokens', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like xrp_send_token or xrp_approve_token. There is no mention of prerequisites, such as requiring a trustline, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the full burden of explaining side effects and prerequisites, but it only states the high-level action. It does not mention that it requires owner keys, that it is an on-chain transaction, irreversibility, or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, but it largely restates the tool name ('Complete an escrow' ≈ 'finish_escrow') and adds only 'release funds' as new information. It is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial transaction tool with no output schema and no annotations, this description is severely incomplete. It does not explain expected return behavior, prerequisites, security implications, or failure scenarios, leaving the agent without enough context to safely execute the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all four parameters with 100% coverage, so the description is not required to add parameter details. It does not add any extra semantics beyond the schema, such as the role of 'fulfillment' in conditional escrows, which keeps it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Complete') and resource ('an escrow') and clarifies the outcome ('release funds'), clearly distinguishing this from sibling tools xrp_create_escrow and xrp_cancel_escrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as conditions for completion (time lock, fulfillment) or when cancellation is appropriate. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to cover return format, pagination, side effects, or any operational constraints, leaving the agent without critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the tool's purpose directly and economically. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is too sparse. It does not explain what the returned data looks like, whether pagination applies, or any limitations, making it insufficient for robust agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'address' parameter with 100% coverage. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('NFTs'), and the scope ('owned by an account'). This distinguishes it from sibling tools like xrp_get_account_objects by specifying the exact asset type and ownership condition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives. It does not mention any exclusions, use cases, or comparisons to other XRP query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It merely states the action without revealing whether the tool validates the blob, what the return structure looks like, or any error conditions. The lack of detail on the decoding behavior is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is appropriately sized for a simple tool, earning a top score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate, but it doesn't cover what the decoded output contains or any important usage caveats. Sibling tools show a rich context, and this tool could benefit from a bit more detail to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with the description 'Signed transaction blob' for the single parameter. The tool description adds no further semantic meaning, so it meets the baseline but doesn't enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Decode a transaction blob' clearly states the action (decode) and the resource (transaction blob), and it distinguishes from sibling tools that create or send transactions. However, it doesn't elaborate on what decoding entails, leaving some ambiguity about the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like xrp_get_transaction or xrp_send_transaction. There are no context hints or exclusions, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It indicates a read operation ('Get') but does not disclose what information is returned, potential errors (e.g., invalid ledger index), or any side effects. The parameter description covers 'validated' but the tool description adds no behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or filler content. It efficiently conveys the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally viable but lacks specifics about the returned ledger information (e.g., header, transactions, metadata). Without an output schema, more detail would improve completeness, but the essential purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the blockNumber parameter described as 'Ledger index or "validated"'. The tool description's 'by number' adds minimal meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get ledger (block) information by number' uses a specific verb and resource, clearly indicating the operation and what is retrieved. It distinguishes from sibling tools like xrp_get_ledger_entry or xrp_get_transaction by focusing on block-level data, though it does not explicitly name alternatives or scope qualifiers beyond 'by number'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description only states what the tool does and does not mention when to use it instead of other tools, any prerequisites, or exclusions. There is no 'use this when' or 'see also' language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states that the tool retrieves guidance but gives no details about side effects, prerequisites, or what the response contains. It doesn't even explicitly state it's a read-only operation. This lack of behavioral disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word is purposeful, and there is no redundancy or filler. It achieves maximum clarity with minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is somewhat incomplete. It doesn't explain what 'guidance' will look like or how it should be used, and with no annotations, the agent lacks context on the tool's role. However, the tool is relatively simple, and the description covers its basic purpose, so it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters, and the description names 'specific XRP operations' which aligns with the 'operation' parameter. However, the description adds no additional meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get conversation prompts and guidance for specific XRP operations'. It identifies a specific resource (conversation prompts) and a scope (specific XRP operations), which differentiates it from sibling tools that execute operations directly. However, it doesn't explicitly name an alternative or contrast with related tools, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like 'use this when you need to construct a conversation prompt' or exclude cases where it shouldn't be used. The user must infer usage context from the tool name and description, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'real-time' without explaining that the subscription is persistent, how to unsubscribe, connection lifecycle, or what events look like. It also fails to mention any required authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no fluff. It earns its place by stating the core purpose, though it could have been more informative with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a live subscription mechanism) and the absence of an output schema or annotations, the description is incomplete. It does not explain what the response/stream contains, how to handle multiple streams, or the implications of subscribing (e.g., resource usage).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (streams and accounts are described), so the baseline is 3. The tool description adds no additional parameter meaning; it only restates the broad action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (subscribe) and the resource (real-time ledger updates), distinguishing it from the many data-retrieval tools among siblings. However, 'ledger updates' is narrower than the schema's mention of streams (ledger, transactions, etc.), so it's slightly imprecise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'real-time' implies this tool is for live updates rather than one-time queries, which contrasts with the sibling get_* tools. But there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives like polling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral context. It fails to disclose that this creates an on-ledger transaction, requires a private key for signing, incurs fees, or modifies NFT ownership status. The brief phrasing 'Create buy or sell offer' gives no insight into side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently communicates the core action and target in just seven words, earning its place without redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a transaction-creating tool with no annotations and no output schema, the description is severely incomplete. It does not mention what happens after creation (e.g., resulting transaction hash), the need for destination optionality, the impact on the NFT, or any prerequisites (e.g., holding the NFT for a sell offer). The sparse description leaves the agent without a clear picture of tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides; the 'buy or sell' phrasing simply restates the flags parameter semantics ('1 for sell offer, 0 for buy'). No additional clarity about format, defaults, or interactions is offered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create buy or sell offer for NFT' uses a specific verb ('Create'), identifies the exact resource (buy/sell NFT offer), and clearly distinguishes this from sibling tools like accept_nft_offer (accepting offers) or get_offers (retrieving offers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for creating offers, while accepting or listing offers is handled by different tools. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the generation of a wallet with address and keys but does not mention whether it is a local/offline operation, whether it interacts with the network, whether the keys are stored, or any security implications. Minimal disclosure beyond the basic output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is directly to the point. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is minimally viable but lacks context. It does not mention testnet vs mainnet, how the wallet relates to funding or importing, or any caveats. Without annotations or an output schema, the description leaves some ambiguity about what the agent should expect beyond a raw address and keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. It appropriately mentions the output (address and keys) which serves as the semantic focus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate new XRP wallet with address and keys' uses a specific action verb and clearly states the output (address and keys). It distinguishes from siblings like xrp_import_wallet (importing an existing wallet) and xrp_generate_address (generating just an address), though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as xrp_import_wallet or xrp_generate_address. The description implies 'new wallet' but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'free APIs' but does not explain potential limitations like rate limits, token consumption, failure modes, or whether the tool performs network calls. It also does not describe what the output looks like (e.g., image URL, file path, base64), leaving the agent without critical behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the core purpose. It front-loads the action and resource, with the API list as a secondary detail. Every word contributes to the tool's definition, with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and no output schema or annotations, the description provides minimal contextual information. It does not clarify the return format, whether the image is stored persistently, how it connects to NFT minting workflows (e.g., xrp_mint_nft_with_ipfs), or any side effects. The tool is effectively a black box, leaving the agent to guess at important integration aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond the schema. It lists API names but does not map them to parameters (e.g., which style works best with which API) or explain potential trade-offs like quality versus speed. Thus, it does not go beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating an AI image for NFTs. It identifies the action ('Generate'), the resource ('AI image for NFT'), and even specifies the APIs used (FLUX.1, Stable Diffusion, Playground AI). This distinguishes it from sibling tools like xrp_mint_nft or xrp_get_nfts, which handle minting or retrieval, not image generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing an NFT project), when not to use it, or how it relates to sibling tools like xrp_mint_nft_with_ipfs. The context of 'for NFT' implies a pre-minting step, but this is not stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Validate XRP address format' and does not explain whether the validation is purely syntactic, whether it queries the XRP ledger for account existence, what the return format is, or whether any side effects occur. This omission could lead an agent to over-interpret the tool's capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero fluff. Every word contributes to defining the tool's purpose, making it an ideal example of conciseness. No unnecessary details or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin. It fails to specify the return value (e.g., boolean, result object) or the scope of validation (format only vs. ledger existence), which is critical for correct usage. The absence of output details and edge-case behavior makes it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description 'Address to validate' for the only parameter, so the baseline is 3. The tool description adds the 'XRP' context, clarifying that the address must be XRP-specific, but it does not add meaningful parameter semantics beyond the schema. No extra guidance on formats, examples, or preconditions is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'validate' and resource 'XRP address' with a focus on 'format', clearly distinguishing it from sibling tools like xrp_generate_address or xrp_get_account_info. Even without an explicit title, the purpose is immediately obvious and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool or how it relates to alternatives. Its intended use (e.g., before sending or processing an address) is implied by the name and description, but not explicitly stated, and there is no mention of exclusions or alternative validation approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states only 'Cancel an existing DEX order' without mentioning that this is a state-changing operation, requires the private key of the order owner, is irreversible, or what happens if the order does not exist. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. It contains no filler and every word contributes to clarity. It is appropriately sized for a tool with only two simple parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two required parameters, and the schema covers them thoroughly. However, the description lacks context about usage scenarios, side effects, or how to obtain the offer_sequence. It is minimally adequate but leaves gaps in understanding the full operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'privateKey' and 'offer_sequence' already clearly described. The description does not add any additional meaning to the parameters, so a baseline score of 3 is appropriate as the schema already handles semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Cancel' and the resource 'existing DEX order,' making the tool's primary function immediately clear. It also distinguishes this tool from siblings like xrp_place_order and xrp_cancel_escrow, as it explicitly targets DEX orders rather than other order types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing to own the order, or how it relates to placing orders or getting order book data. There is no indication of when to prefer this over xrp_cancel_escrow or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and purpose, but omits side effects, prerequisites, on-ledger implications, or reversibility. This is too thin for a mutating blockchain operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse and front-loaded with the verb. It wastes no words, though it is minimal in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is inadequate for a complete understanding. It explains what the tool does but not what it returns, what the trustline entails, or any special requirements, which are critical for a create transaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (100% coverage), so the description adds no extra parameter meaning. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('trustline') with a specific purpose ('to hold a custom token'). It distinguishes itself from sibling tools like xrp_remove_trustline and xrp_get_trustlines by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to hold a custom token' implies the use case, but the description offers no explicit guidance on when to choose this tool over alternatives or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states that it retrieves escrows and does not mention whether it is a read-only operation, whether it requires authentication, or what pagination or response format to expect. The term 'get' weakly implies a read but offers no concrete behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words or repetition. It communicates the core function efficiently, though the brevity comes at the cost of behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), and the description specifies the basic function. However, it does not clarify what an escrow is, what the return payload looks like, or whether pagination applies when retrieving 'all' escrows. Thus, it is minimally complete but lacks detail for an agent to fully anticipate the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter ('address' as 'Account address'), and the description's 'for an account' adds no new meaning beyond the schema. Therefore, the description does not enhance understanding of the parameter's purpose or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('escrows'), and the scope ('for an account'). This distinguishes it from sibling tools that create, finish, or cancel escrows, and from other retrieval tools like xrp_get_offers or xrp_get_ledger_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention excluded scenarios, alternative tools, or prerequisites. The appropriate use case is implied by the verb and resource, but there is no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the action ('Get') but does not mention whether the operation is read-only, what happens if the entry is not found, or any other behavioral traits. The implied read-only nature is not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to the meaning, making it extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity and high schema coverage, the description is minimally adequate. However, with no output schema and no annotations, the description does not explain what the return value is or provide enough context for an agent to fully understand the tool's role versus siblings. It is a bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds a small semantic hint with 'by ID', pointing toward the 'index' parameter, but does not clarify relationships between optional parameters like ledger_index and ledger_hash. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get specific ledger entry by ID' uses a specific verb ('Get') and a clear resource ('ledger entry') with the key qualifier 'by ID'. This distinguishes it from sibling tools like xrp_get_account_info or xrp_get_transaction, making its purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not clarify when a user should choose this over xrp_get_account_objects or how it relates to ledger hashes/indexes. The description omits any contextual or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention any side effects, permissions, rate limits, or details about what the returned network configuration includes. The 'Get' verb implies a read-only operation, but no further transparency is offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It effectively communicates the tool's purpose in a concise manner, earning a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides adequate context by naming the resource and the kind of information retrieved. However, it could be slightly more specific about what 'network configuration' includes, but for this simple tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. According to the baseline for 0-parameter tools, a score of 4 is appropriate. No additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving XRP Ledger network configuration and connection status. It uses a specific verb ('Get') and a resource ('network configuration and connection status'). While it doesn't explicitly differentiate from sibling tools like xrp_get_chain_info, the purpose is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios or exclusions, leaving the agent to infer usage from the name alone. Given the presence of similar network-related sibling tools, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Get token trustline limit', which implies a read-only operation, but does not describe response format, error conditions, permissions, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'Get'. It has no filler and every word adds meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with no output schema, the description identifies the resource but does not elaborate on the return structure, possible error cases, or how the allowance is calculated. It is minimally adequate but lacks enough context for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with clear descriptions (issuer, address, currency), achieving 100% coverage. The description adds the context that this is about a 'trustline spending allowance', but does not explain parameter relationships or the meaning of the returned value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'token trustline limit (spending allowance)', which clearly distinguishes it from siblings like xrp_get_trustlines and xrp_get_token_balance. It directly states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as xrp_get_trustlines or xrp_get_token_balance. The description only states the action, with no mention of preferred use cases, exclusions, or relationships to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states a read operation implicitly ('get') but does not disclose side effects, permissions, error behavior, or that the result is on-ledger data. The description adds no context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core function. It is appropriately sized and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is minimally viable but lacks contextual details such as what 'details' means, whether it returns raw or decoded data, and any prerequisites or error conditions. It does not fully prepare an agent for all invocation scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the only parameter 'hash' has a description 'Transaction hash'. The description's 'by hash' aligns with the schema but does not add additional semantic detail. It meets the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get transaction details by hash' with a specific verb ('get') and resource ('transaction details'), and identifies the unique lookup key (hash). This distinguishes it from sibling tools like xrp_get_transaction_history and xrp_decode_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of alternative tools or any exclusions, so the description relies solely on the implied use case of having a transaction hash, which is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It only mentions the high-level action of creating an NFT and IPFS storage, but omits critical behavioral details such as irreversible ledger mutation, need for IPFS credentials, potential fees, and whether images are uploaded immediately. This is insufficient for a transaction-signing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and efficiently conveys core purpose. However, the parenthetical 'Enhanced version of xrp_mint_nft' is slightly vague and could be replaced with a more concrete differentiator, but it does not add unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 10 parameters, no annotations, and no output schema, making it relatively complex. The description is too brief: it does not explain the overall workflow (e.g., how images are uploaded), prerequisites like IPFS API keys, what the return value contains, or side effects. The schema describes parameters but not the end-to-end behavior, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptive text for every parameter, so the baseline is 3. The description itself adds no additional parameter-specific semantics beyond what the schema already conveys; it merely reiterates the IPFS aspect already covered by imageUrl and imagePath descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create NFT') with a specific method ('with IPFS storage for images and metadata'). It also distinguishes itself from the sibling tool xrp_mint_nft by calling itself the 'Enhanced version', making its unique purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for NFT creation with IPFS storage, which indicates when to use it, but it does not explicitly provide alternatives or exclusions. It does not state when to prefer the base xrp_mint_nft tool instead, leaving the guidance at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. 'Burn' implies destruction, but it never states that the action is irreversible, does not mention any prerequisites beyond ownership, or what happens to the NFT's offers. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five words long, front-loads the action, and contains no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple mutation with only two parameters, but with no annotations and no output schema, the description alone is inadequate. It fails to communicate the irreversible nature of the burn, potential side effects, or the expected return value, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear descriptions ('NFT Token ID to burn' and 'Owner private key'). The description adds no additional parameter meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'burn' and the resource 'NFT', and qualifies it with 'you own', which clearly distinguishes it from sibling tools like mint_nft or create_nft_offer. It conveys exactly what the tool does in a compact phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you own an NFT and want to permanently destroy it, but it does not explicitly state when not to use it or mention alternatives. It's a single sentence with no contextual guidance beyond the implied ownership condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Cancel an expired escrow' without detailing side effects (e.g., funds returned to owner), irreversibility, or any prerequisites beyond what the schema already lists. This is a mutation tool, and the lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or redundant content. It front-loads the action and condition efficiently, earning its place in the limited space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too terse. It omits important contextual details such as when to use it, prerequisites, consequences of cancellation, and potential errors. The near-identical purpose is already implied by the tool name, so the description adds little beyond that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (privateKey, owner, escrow_sequence) having a clear description. The tool description adds no additional semantic value or relationships between parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel an expired escrow' uses a specific verb ('Cancel') and resource ('escrow'), and specifies the condition 'expired' to clarify the scope. This clearly distinguishes it from sibling tools like xrp_finish_escrow (which finishes an escrow) and xrp_create_escrow (which creates one).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an escrow is expired, but does not explicitly state when to use this tool versus alternatives such as xrp_finish_escrow. No exclusion criteria or alternative tool names are mentioned, so 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states a high-level action and lock types, omitting side effects, fees, required permissions, or consequences (e.g., funds being locked). This is a significant transparency gap for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence without redundant phrasing or filler. It efficiently conveys the core action and key differentiators.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, lock conditions, timestamps) and lack of output schema, the description is too minimal. It does not explain how escrow usage flows, what 'time' or 'condition' locking implies, or what happens upon creation, leaving the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 6 parameters with 100% coverage. The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and explicit resource ('escrow'), clearly distinguishing it from siblings like finish, cancel, or get. It also identifies the two locking modes (time or condition), which adds specificity beyond just 'create an escrow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'Create' relative to sibling tools (xrp_finish_escrow, xrp_cancel_escrow, xrp_get_escrows), but there is no explicit guidance on when to choose this tool instead of alternatives, nor any exclusions or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey safety and behavior. 'Get' implies a read operation, but it does not explicitly state that it is non-mutating, does not mention what happens for invalid or non-existent accounts, and gives no indication of response structure or error conditions. The promise of 'complete' information is vague without further detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes meaning: it names the action, the resource, and two key content areas ('balance and settings'). It is appropriately concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no annotations and no output schema, the description gives a reasonable overview of purpose and key return aspects (balance and settings). It does not enumerate all possible fields, but 'complete account information' implies an exhaustive set. The lack of alternative guidance slightly reduces completeness, but the tool's simplicity keeps the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter ('address' described as 'XRP account address'). The description adds no additional meaning about the address format or how it affects the returned data, so it remains at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('complete account information'), explicitly listing 'balance and settings' as included content. This distinguishes it from siblings like xrp_get_balance (balance only) and xrp_get_wallet_info (wallet-specific info), making the tool's unique scope evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as xrp_get_balance, xrp_get_account_objects, or xrp_get_wallet_info. The description does not mention any exclusions, prerequisites, or scenarios that would favor one sibling over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. The verb 'Get' implies a read-only operation, but the description does not disclose return format, network requirements, or failure modes. It is acceptable for a simple getter but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, efficiently communicating the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its simplicity, the description is too terse for the context. It does not specify what the tool returns, how to handle different address formats, or how it differs from similar balance tools like xrp_get_token_balance, which would aid selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete documentation for the 'address' parameter, and the description adds no additional meaning beyond the schema. Baseline of 3 applies due to high schema coverage (100%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('XRP balance'), and the target ('for an address'), making its purpose unambiguous and distinct from sibling tools like xrp_get_token_balance and xrp_get_account_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when to choose it over xrp_get_token_balance or xrp_get_account_info, leaving the selection criteria unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the action without mentioning side effects, security implications, whether the seed is stored, or what the tool returns. This is a significant gap for a wallet-related operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action and object. It contains no filler or redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter, but the description does not explain what the tool returns after import, whether it validates the seed, or how it differs functionally from creating a wallet. With no output schema, the agent lacks essential context to anticipate the outcome, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter 'seed' as a string starting with 's', achieving 100% coverage. The description adds no additional information about the parameter beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Import' with the resource 'existing XRP wallet' and the method 'from seed', making it distinct from sibling tools like xrp_create_wallet or xrp_generate_address. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the verb 'Import' and the phrase 'existing XRP wallet', suggesting it is for wallets that already exist. However, the description does not explicitly state when to use this tool over alternatives like xrp_create_wallet, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'set limit to 0', implying a mutable operation, but does not disclose that it submits a signed transaction, requires fees, or produces a transaction hash. It also does not mention reversibility or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with seven words, front-loaded with the verb and resource. It contains no fluff or redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no output schema and no annotations, yet the description provides minimal context. It does not explain return values, transaction signing, fee requirements, or network effects, making it incomplete for an agent to understand the full implications of invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions; the phrase 'set limit to 0' provides context but not parameter-specific semantics. It neither clarifies formats nor adds missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action verb 'Remove' and the resource 'trustline', with the semantic clarification 'set limit to 0'. This unambiguously distinguishes it from sibling tools like xrp_create_trustline or xrp_get_trustlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for removing a trustline, which is clear in context. However, it does not explicitly mention when to use this tool versus alternatives (e.g., create or get trustlines), nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that sending a transaction may have irreversible effects, require signing with a private key, or incur network fees. The one-line description lacks transparency about the operational impact and requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is appropriately sized and front-loaded, delivering the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too sparse for a transaction tool. It omits key context such as how the private key is used, whether the transaction is broadcast automatically, and potential side effects like irreversible fund transfer or network fees.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all three parameters (to, amount, privateKey). The tool description does not add extra meaning or clarify relationships between parameters, so it meets the baseline but offers no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (Send), resource (XRP), and destination (another address), which unambiguously distinguishes it from sibling tools like xrp_send_token or xrp_transfer_token. It is concise and precisely conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the tool name and description: it is for sending XRP, not other tokens. However, no explicit guidance is provided on when to choose this tool over alternatives such as xrp_send_token or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action without mentioning consequences such as irreversible blockchain transaction, fees, offer consumption, or required authorization beyond the privateKey parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that directly states the tool's function with no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required parameters, no output schema), the description is adequately complete for basic use. However, it does not explain the on-chain transaction nature, possible failures, or what happens after acceptance, which is a minor gap for a financial action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—both privateKey and offer_id have descriptions in the input schema. The tool description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Accept an NFT buy or sell offer' uses a specific verb ('Accept') and identifies the resource ('NFT buy or sell offer'), distinguishing it clearly from sibling tools like xrp_create_nft_offer and xrp_get_offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the action verb 'accept'—if an agent wants to accept an NFT offer, this is the tool. However, there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It implies a read operation but doesn't mention any potential side effects, rate limits, caching behavior, or response format. The minimal wording does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded with the action verb 'Get' and free of any redundant information. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description covers the essential purpose and unit, but it does not describe the return value structure (e.g., a single number vs. a breakdown by fee levels). With no output schema and no annotations, the description is minimally viable but leaves the agent guessing about the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for zero-parameter tools is 4, and the description adds meaningful context by specifying the unit 'drops', which the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' combined with the resource 'transaction fee (gas) pricing' and the unit 'drops', making the purpose unambiguous. It clearly distinguishes this tool from siblings like xrp_estimate_fees by specifying 'current' pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as xrp_estimate_fees or xrp_get_network_info. It only states what it does, leaving the agent without comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read operation via 'Get' but does not disclose behavior like whether a trustline must exist, what happens if it does not, or any error cases. It adds no context beyond the verb and the notion of a trustline balance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of one short sentence that directly states the tool's function. It is front-loaded with the action and resource, and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three well-documented parameters, the description is minimally adequate. However, with no output schema and no annotations, it would benefit from explaining the return format or edge cases (e.g., trustline not found). It is not misleading but leaves some gap in what the agent can expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters (address, currency, issuer). The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'custom token (trustline) balance' for an account. This clearly distinguishes it from sibling tools like xrp_get_balance (which likely retrieves XRP balance) and xrp_get_trustlines (which lists trustlines rather than a specific balance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for custom token balances, but it does not explicitly state when to use this tool versus alternatives such as xrp_get_balance or xrp_get_trustlines. No exclusions or alternative recommendations are provided, so usage guidance is only implied by the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the function without disclosing whether the operation is read-only, the structure of the response, pagination behavior, or any edge cases. The agent is left without details about side effects or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states exactly what the tool does with no redundant words. It is efficiently concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple getter tool with one parameter and no output schema. The description and schema together provide the essential function and parameter, but the absence of output schema and behavioral details leaves minor gaps. It is adequate for a basic list operation, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the 'address' parameter with the description 'Account address'. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'all trustlines for an account'. This distinguishes it from sibling tools like xrp_create_trustline and xrp_remove_trustline, which involve different actions. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs all trustlines for a specific account, but it does not explicitly mention alternatives or when not to use this tool. The scope is clear from the wording, but no exclusions or comparative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately states the core behavior (funding a testnet account with test XRP) but does not disclose potential side effects, prerequisites, or whether the operation is reversible. The statement is clear but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and directly states the action. Every word contributes to clarity, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is largely sufficient. It clearly communicates the tool's purpose and the parameter's role. However, it omits any mention of constraints (e.g., address must be a testnet address) or what happens after successful funding, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'address' described as 'Address to fund'. The description adds no additional meaning beyond this, so the baseline score of 3 is appropriate; the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fund') and clearly identifies the resource ('a testnet account') and the object ('test XRP'). It distinguishes itself from sibling tools like xrp_send_transaction or xrp_create_wallet by explicitly targeting testnet funding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of e.g., using this instead of xrp_send_transaction for testnet purposes, or any prerequisites like needing a testnet address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. The verb 'Get' implies a read-only operation, and the phrase 'open ledger (mempool)' adds useful scope, but it does not detail what 'statistics' includes or any rate limits or safety aspects. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, containing no filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (zero parameters, no output schema), the description adequately conveys the tool's purpose. It could be slightly more specific about what 'transaction statistics' entails, but for this simple tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is effectively 100%. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description adds no parameter semantics because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies a distinct resource: 'open ledger (mempool) transaction statistics'. This clearly differentiates it from sibling tools like xrp_get_chain_info or xrp_get_block, leaving little ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving current mempool/open ledger statistics, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. It provides context but lacks direct comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![xrp-testnet-mcp-server MCP server](https://glama.ai/mcp/servers/MyronKoch/xrp-testnet-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/MyronKoch/xrp-testnet-mcp-server)

Score Badge

Copy to your README.md:

[![xrp-testnet-mcp-server MCP server](https://glama.ai/mcp/servers/MyronKoch/xrp-testnet-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/MyronKoch/xrp-testnet-mcp-server)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MyronKoch/xrp-testnet-mcp-server'

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