xrplme.online gives AI agents source-backed economic and regulatory data for 30 countries, paid per query in XRP over the x402 micropayment protocol on the XRP Ledger. Its MCP server exposes tools to list countries, check country status, read pricing, and run regional research — no API keys and no accounts: agents read the public manifest and pay per call.
Scored across 9 tools
Most tools are distinct, but the trio get_country_data / get_country_schema / get_country_status share a very similar surface and could be confused at a glance; descriptions (full data vs field schema vs free health probe) do help differentiate. regional_research also overlaps somewhat with get_country_data but is clearly marked as a staging prototype.
All tools use a consistent xrplme_ prefix with snake_case verb_noun structure (get_country_data, list_countries, submit_survey). The pattern is predictable and readable throughout.
9 tools is well-scoped for a country-data/payment service, with each tool (list, per-country data/schema/status, pricing, research, survey trio) earning its place.
Covers listing, per-country data/schema/status, pricing, regional research, and a full survey lifecycle (questions, submit, stats). Minor gaps: no bulk multi-country fetch and no update/delete operations, but for a read-oriented data service the core surface is solid.
Latest data + freshness for one country. REQUIRES PAYMENT: 0.5 XRP (AI-parsed).
Args:
slug: Country slug (e.g., "thailand")
x_payment_signature: JSON string containing tx_hash AND signedTxBlob
(hex-encoded signed XRPL tx). Both are required: the t54
facilitator decodes the blob to bind the on-chain InvoiceID.
x_inv_id: Invoice ID
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| x_inv_id | No | ||
| x_payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses a mandatory 0.5 XRP payment, that both tx_hash and signedTxBlob are required, and the non-obvious mechanic that the t54 facilitator decodes the blob to bind the on-chain InvoiceID. It still omits failure behavior (what happens on invalid/insufficient payment) and any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-line purpose and payment flag, then a compact args block. The two-line signature explanation is longer but every clause encodes required information (both fields mandatory, blob is hex, facilitator binds InvoiceID).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, no-annotation, no-output-schema tool, the description covers the payment precondition, signature construction, and country scoping adequately. The main omission is how to discover the required Invoice ID and any error/refund semantics, but nothing needed to attempt a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate and largely does: it gives a concrete example for slug ('thailand'), and explains the two-part composition of x_payment_signature plus why both halves are required. x_inv_id is only glossed as 'Invoice ID' with no format or sourcing guidance, which is the one thin spot.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('get country data') and a clear scope ('one country') with the distinctive payload 'latest data + freshness'. However, it does not differentiate from the closely-named sibling xrplme_get_country_status or xrplme_get_country_schema, leaving the agent to guess which one carries status vs schema vs the data payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance and never names an alternative, despite eight siblings including an obviously overlapping xrplme_get_country_status. The payment note describes a precondition, not a usage rule, so the agent has no routing signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Field schema for one country. REQUIRES PAYMENT: 0.1 XRP (standard).
Args:
slug: Country slug (e.g., "thailand")
x_payment_signature: JSON string containing tx_hash AND signedTxBlob
(hex-encoded signed XRPL tx). Both are required: the t54
facilitator decodes the blob to bind the on-chain InvoiceID.
x_inv_id: Invoice ID
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| x_inv_id | No | ||
| x_payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses a concrete behavioral constraint no structured field provides: this is a paid call costing 0.1 XRP, requiring a signed XRPL transaction. However, it does not describe the return format or the failure/validation behavior of the payment gate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the critical payment requirement are front-loaded, and the Args block is compact with no filler. Structure is efficient, though the signature explanation is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should explain what a 'field schema' actually returns; instead it only covers the payment gate and parameters. The paid-auth mechanics are well covered, but the payload an agent receives is left undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does well for two of three params: slug is exemplified ('thailand') and x_payment_signature is explained in detail (JSON string with tx_hash AND signedTxBlob, hex-encoded XRPL tx, both required, facilitator binds InvoiceID). Only x_inv_id is left as a bare 'Invoice ID', a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it returns a 'Field schema for one country', giving a resource but no clear verb and no differentiation from siblings like xrplme_get_country_data or xrplme_get_country_status. An agent cannot easily tell whether this returns the schema definition of a country's fields or the country data itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of the alternative siblings (get_country_data, get_country_status) or when this schema lookup is appropriate. The only routing hint is the payment cost, not a use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live free health probe for one country. FREE.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the probe is live and free, but says nothing about authentication, rate limits, response format, or what a health result contains. For a read-only probe this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the core idea, but 'FREE.' repeats the already-stated 'free' and functions as marketing rather than useful instruction. Structure is fragmentary rather than deliberately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations and no output schema, the description should at least clarify the slug parameter and what the health probe returns. It leaves both undocumented, so an agent lacks enough context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single slug parameter. The description's phrase 'one country' implies the slug identifies a country, adding minimal meaning, but it does not explain the expected format, source, or behavior when the default empty string is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: a live health probe for one country. It is clear enough to identify the tool's resource and action, though it does not explicitly distinguish itself from siblings like xrplme_get_country_data or xrplme_get_country_schema beyond the word 'health probe'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no alternatives, and no preconditions. 'Live free' hints at availability but does not help an agent choose between this tool and the many other country/survey/research tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Standard pricing: 0.1 XRP (standard); 0.5 XRP (AI-enhanced). FREE.
The legacy "tourism" key is retained as a deprecated alias for "standard"
(both resolve to 100000 drops / 0.1 XRP) for backward compatibility.
Prefer "standard". Will be removed in MCP API v2.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No |
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 mentions backward compatibility and that the 'tourism' alias will be removed in MCP API v2, but it does not state whether the tool is read-only, what it returns, how errors are handled, or any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and front-loads the pricing tiers before the deprecation note. It is mostly free of filler, though the formatting with quotes, parentheses, and line breaks makes it slightly harder to parse than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description should at minimum clarify the tool's action and the role of the slug parameter. It omits both, leaving the agent to guess what a call actually returns or how slug filters the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies valid values for the slug parameter ('standard', 'AI-enhanced', and the deprecated 'tourism') and explains how 'tourism' resolves, which adds real meaning. However, it never explicitly maps these values to the slug parameter or says what happens when slug is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Standard pricing: 0.1 XRP...' which reads like a pricing table rather than a statement of what the tool does. It never says 'returns pricing' or 'gets pricing for a given slug,' so the agent must infer the tool's action largely from the name. It does not distinguish this tool from siblings like get_country_data beyond the topic of pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool versus alternatives. The note to 'Prefer standard' concerns a parameter value, not tool selection, and there is no mention of prerequisites or typical scenarios for using the pricing endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get survey questions for AI agents to provide feedback. FREE.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 usefully discloses that the call is FREE, which is a meaningful behavioral trait, but it does not state read-only status, authentication requirements, rate limits, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short fragments front-load the action and then the audience/cost. Every word earns its place, with no redundancy or buried information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter read tool with no output schema, the description covers what it does and that it is free. However, it omits the natural next step (submitting answers via submit_survey) and does not explain the format of the returned questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to clarify beyond the empty schema. The baseline for zero-parameter tools is 4, and the description adds no confusing or contradictory parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (get) and resource (survey questions), and the added purpose 'for AI agents to provide feedback' distinguishes it from sibling tools like get_survey_stats and submit_survey. An agent can tell exactly what this tool returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for AI agents to provide feedback' implies the intended use context (fetch questions before submitting feedback), but it never explicitly states when to call this versus submit_survey or get_survey_stats. Usage is only implied, not clearly instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated survey statistics from all AI agents. FREE.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds only that the tool is 'FREE,' omitting read-only implications (though 'Get' hints at it), authentication needs, rate limits, data freshness, and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the tool's purpose and a key cost attribute. Every word earns its place with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain what statistics are returned (e.g., counts, averages, distributions) or when to use this tool over siblings. For an agent to invoke it correctly, more context about the return values and intended use is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain any parameters, and none are present to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('aggregated survey statistics') with scope ('from all AI agents'). It clearly distinguishes itself from submission-oriented siblings like submit_survey, but does not explicitly name or contrast with alternatives such as get_survey_questions or regional_research.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are any exclusions or prerequisites stated. The only contextual note is 'FREE,' which addresses cost but not usage selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 30 countries. FREE.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool lists 30 countries and is free, but doesn't explain the return format, whether it's paginated, or what 'free' entails in context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It's extremely concise at just 4 words, front-loading the core purpose. Every word earns its place, though it could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling tools and lack of output schema, this description is minimal. It doesn't clarify what data is returned about each country or how it relates to other country-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 count), so baseline 4 is appropriate. No parameter semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It has a clear verb and resource ('List the 30 countries'), so the agent knows exactly what the tool returns. However, it doesn't differentiate itself from siblings like xrplme_get_country_data or xrplme_get_country_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus siblings. 'FREE' hints at pricing considerations but doesn't explicitly state alternatives or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
STAGING prototype (unpaid, feature-flagged, NOT live-verified). Accepted countries: vietnam, japan, singapore. Accepted dimensions (max 4): formation, immigration, labor, operating_environment. Roadmap-only (rejected): tax, foreign_ownership, permits, economy. Returns explicit unknowns where coverage is missing. Informational only.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | standard | |
| countries | Yes | ||
| objective | Yes | ||
| dimensions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses staging status, unpaid/feature-flagged, NOT live-verified, 'informational only', and that it returns explicit unknowns where coverage is missing. It omits auth needs, rate limits, and return shape, but the limitation disclosure is unusually candid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the most decision-relevant caveat (staging, not live-verified), then lists scope and exclusions in terse fragments. Every line carries information; only minor tightening is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param, no-output-schema, no-annotation tool, the description covers scope and limitations well but leaves objective and depth semantics and the actual response structure unstated. An agent still lacks enough to invoke it fully correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 4 params, so the description must compensate. It documents countries and dimensions (including the max-4 rule and rejected values) effectively, but 'objective' and 'depth' are entirely undocumented, leaving two of four parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates accepted countries and research dimensions, which implies a multi-country business-environment research tool, but it never states an explicit verb+resource outcome (what a 'research' call actually returns beyond 'explicit unknowns'). An agent can infer the scope from the enum-like lists, yet the core purpose remains implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives strong in-scope guidance (accepted countries, accepted dimensions, max 4) and an explicit out-of-scope list (roadmap-only: tax, foreign_ownership, permits, economy). However, it never names a sibling tool or says when to prefer this over xrplme_get_country_data or xrplme_list_countries, so alternative selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit survey feedback from an AI agent. FREE (we pay you for testing!).
Args:
agent_id: Your AI agent identifier
country_slug: Country you tested (e.g., "thailand")
data_quality: Rating 1-5
completeness: Rating 1-5
pricing_fair: "yes", "no", or "depends_on_country"
would_pay_again: "yes", "no", or "maybe"
broken_fields: Text description of any broken fields
improvements: Text suggestions for improvements
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| completeness | No | ||
| country_slug | Yes | ||
| data_quality | No | ||
| improvements | No | ||
| pricing_fair | No | ||
| broken_fields | No | ||
| would_pay_again | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It states submission is FREE, which is a useful economic fact, but says nothing about whether submission is one-shot or updatable, what happens on duplicate agent_id/country pairs, or what the caller receives. For a mutation tool with zero annotation coverage this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and benefit, followed by a compact args list; each line earns its place. The marketing parenthetical is minor waste but does convey that submission is free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter write tool with no output schema and no annotations, the description documents all inputs reasonably but omits submission semantics (repeat submissions, required fields, relationship to get_survey_questions). Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry all parameter meaning — and it does list every parameter with useful hints: country_slug example ('thailand'), data_quality 'Rating 1-5', and explicit allowed values for pricing_fair and would_pay_again. It omits agent_id format and does not mark which fields are required, which the schema conveys separately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a clear verb+resource: submitting survey feedback. This is inherently separable from the sibling get_/list_ tools, though no sibling is named explicitly and the parenthetical 'we pay you for testing!' adds noise rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to submit versus when to gather data first — notably a sibling xrplme_get_survey_questions exists and presumably should be consulted before submitting, but this is not mentioned. No exclusions, prerequisites, or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
xrplme_get_country_dataxrplme_get_country_schemaxrplme_get_country_statusxrplme_get_pricingxrplme_get_survey_questionsxrplme_get_survey_statsxrplme_list_countriesxrplme_regional_researchxrplme_submit_survey
Add one secure layer between your agents and this server.