Source-backed country policy data for AI agents; pay-per-call via x402 (XRP or USDC).
Scored across 9 tools
Country-scoped tools are separable by purpose: data retrieval, schema retrieval, and free status probing are distinct, while list/pricing/survey tools have clear roles. Minor overlap risk exists between get_country_status and freshness in get_country_data, and regional_research conceptually overlaps with country data, but descriptions mostly disambiguate.
All tool names use the xrplme_ prefix and snake_case, with mostly predictable verb_noun patterns such as get_*, list_*, and submit_*. The only notable deviation is regional_research, which is a noun phrase rather than a verb-led action name.
Nine tools is well within the appropriate range for a focused country-intelligence server. The surface covers distinct workflows—listing, retrieval, pricing, payment-gated data, regional research, and survey feedback—without excessive tool sprawl.
The server covers country discovery, paid data/schema retrieval, free status, pricing, regional research, and the full survey lifecycle. Minor gaps remain: there is no tool to obtain invoice/payment context despite paid tools requiring x_inv_id, and regional_research is explicitly staging/partial rather than a complete standard retrieval path.
Latest data + freshness for one country. REQUIRES PAYMENT.
XRPL : 5 XRP via x_payment_signature + x_inv_id
Solana : $7.00 USDC via x_sol_payload
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
x_sol_payload: OPTIONAL. base64 of an x402 PaymentPayload paying USDC
on Solana. When present it is verified AND settled via the local
facilitator; the XRPL arguments are then ignored.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| x_inv_id | No | ||
| x_sol_payload | 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 behavioral burden and adds important context: payment is mandatory, XRPL payment requires both tx_hash and signedTxBlob, the facilitator decodes the blob to bind InvoiceID, and Solana payment is verified and settled locally. It does not cover error behavior or permission details beyond payment, which keeps it from a 5.
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 definition is front-loaded with purpose and payment requirement, then moves into payment methods and argument semantics. The separate Args section is slightly redundant with the schema parameter names, but it earns its place by adding payment-specific meaning.
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 four-parameter paid tool with no annotations and no output schema, the description covers purpose, payment mechanics, and all parameter meanings well enough to invoke it correctly. It still leaves slug discovery and error handling unstated, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: slug is a country slug such as 'thailand', x_payment_signature is a JSON string containing both tx_hash and signedTxBlob, x_inv_id is the Invoice ID, and x_sol_payload is an optional base64 x402 PaymentPayload. It also explains the interaction between Solana and XRPL arguments, which the schema cannot express.
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 resource and scope: 'Latest data + freshness for one country.' That clearly separates it from list-oriented siblings such as xrplme_list_countries. It does not explicitly name when to use it instead of xrplme_get_country_status or xrplme_get_country_schema, so it stops short of full sibling differentiation.
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 clearly says 'REQUIRES PAYMENT' and explains the two payment paths, including that x_sol_payload overrides the XRPL arguments when present. However, it does not state when an agent should choose this tool over siblings like xrplme_get_country_schema or xrplme_get_country_status, so usage guidance is mostly implied.
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.
XRPL : 1 XRP via x_payment_signature + x_inv_id
Solana : $1.00 USDC via x_sol_payload
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
x_sol_payload: OPTIONAL. base64 of an x402 PaymentPayload paying USDC
on Solana. When present it is verified AND settled via the local
facilitator; the XRPL arguments are then ignored.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| x_inv_id | No | ||
| x_sol_payload | 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 substantial work: it discloses the payment requirement, the two price points (1 XRP / $1.00 USDC), the settlement semantics ('verified AND settled via the local facilitator'), and the precedence rule between payment methods. Gaps remain on failure behavior, whether payment is consumed on error, and what the returned schema looks like.
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 purpose and payment requirement, then a compact Args block. The two-line payment listing and the parenthetical about the t54 facilitator both earn their place; minor redundancy between the payment header and the per-arg notes.
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 paid tool with no annotations and no output schema, the description covers the payment model, all arguments, and the precedence rule. It stops short of describing the shape of the returned field schema, which is the tool's actual payload and would help an agent decide whether to pay.
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: slug gets a concrete example, x_payment_signature is specified as a JSON string containing tx_hash AND signedTxBlob with the reason both are needed, and x_sol_payload is defined as base64 x402 PaymentPayload with its override behavior. x_inv_id remains thin ('Invoice ID'), leaving its origin and format unstated.
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 resource and outcome: 'Field schema for one country', naming the slug argument's purpose. It is distinguishable from data-oriented siblings like xrplme_get_country_data only by implication, since it never explicitly contrasts returning a schema with returning data.
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 clearly frames the call as paid and explains that supplying x_sol_payload supersedes the XRPL path ('the XRPL arguments are then ignored'), which is real routing guidance. However, it gives no guidance on when to choose this tool over xrplme_get_country_data or xrplme_get_country_status, and no prerequisites (wallet setup, how to obtain x_inv_id) are stated.
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.
Pricing on both rails. Standard: 1 XRP or $1.00 USDC. AI-enhanced: 5 XRP or $7.00 USDC. FREE.
Each tier is reported as drops/xrp (XRPL) and usdc/usdc_micro (Solana).
The legacy "tourism" key is retained as a deprecated alias for "standard"
(both resolve to the standard tier: 1000000 drops / 1 XRP, or $1.00 USDC)
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, and it does disclose useful response behavior: dual-rail reporting (drops/xrp on XRPL, usdc/usdc_micro on Solana), a deprecated 'tourism' alias, and a v2 removal timeline. It omits auth requirements, rate limits, and whether/why the payload varies, which matters for a pricing endpoint.
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 is short and front-loads the price table, but it is structured as response documentation rather than a tool description, and the tourism/deprecation paragraph is disproportionate to a single-parameter endpoint. 'FREE.' as a standalone sentence is inefficient.
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?
Absent an output schema, the description usefully documents the expected return keys, which is its main contribution. However, with no annotations and zero parameter documentation, an agent still cannot tell what 'slug' does or what operational constraints apply before calling.
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% and the single 'slug' parameter (default '') is never mentioned. The description cannot compensate for the coverage gap because it says nothing about what a slug selects or how the response changes when one is supplied.
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 opening fragment 'Pricing on both rails' plus the tier list make it inferable that the tool returns the service's price tiers, but there is no explicit verb+resource statement (e.g., 'Returns current pricing for all service tiers'). Nothing distinguishes it from siblings beyond the subject matter, and 'FREE.' dangles without a predicate.
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 statement of when to call this tool, no prerequisites, and no comparison to the eight sibling tools. The only directive, 'Prefer "standard"', concerns which response key to read, not when to use the tool itself.
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 (30, matching slugs.py and the live bot fleet): australia, brazil, brunei, canada, france, germany, hong_kong, india, indonesia, italy, japan, korea, laos, malaysia, macau, mexico, myanmar, netherlands, newzealand, papua-new-guinea, philippines, singapore, switzerland, taiwan, thailand, timor-leste, uae, uk, usa, vietnam. 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 notable work: it labels itself a staging prototype, unpaid, feature-flagged and NOT live-verified, discloses that it returns explicit unknowns where coverage is missing, and marks results informational only. It omits auth requirements, rate limits, and return shape, but the reliability/state disclosure is well above average.
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 staging caveat is front-loaded, followed by structured enumerations. The 30-country list is long but necessary for correctness, and every line carries information; only the objective/depth omission (not an excess) detracts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and 0% schema coverage, the description supplies country and dimension constraints plus the unknowns caveat, which is solid. It still leaves the meaning of 'objective' and 'depth' undefined and gives no hint of result structure or size, so an agent cannot fully predict inputs or outputs.
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 it does for two parameters: it enumerates the 30 valid countries (with slug form) and the four valid dimensions, plus rejected roadmap-only dimensions (tax, foreign_ownership, permits, economy). The required 'objective' and the 'depth' parameter (default 'standard') get no explanation, so the semantic picture is only half complete.
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 tool name plus the enumerated dimensions (formation, immigration, labor, operating_environment) make it clear this is a multi-country, multi-dimension research tool that returns country-level findings. It is distinguishable in principle from the single-country siblings like get_country_data, but the description never explicitly contrasts itself with them.
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 accepted-country list and the max-4 dimension constraint implicitly tell the caller when the tool applies, and 'Informational only' signals no side effects. However, there is no explicit when-to-use guidance versus the eight sibling tools, and no statement of when NOT to call it.
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_regional_researchxrplme_get_country_dataxrplme_get_country_schemaxrplme_get_country_statusxrplme_get_pricingxrplme_get_survey_questionsxrplme_get_survey_statsxrplme_list_countriesxrplme_submit_surveyPay-per-call change-intelligence feeds for AI agents over x402 (deps, security, regs, tariffs)
Pay-per-call crypto data for agents: metrics, claims, custom briefs. USDC via x402.
Pay-per-call US public data for agents: OFAC, SEC, FMCSA, NPI, VIN recalls, SAM.gov. x402 USDC.
Pay-per-call US public data for agents: recalls, weather, climate, SEC filings. x402 USDC on Base.
Add one secure layer between your agents and this server.