XRPLME Country Intelligence

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it does well: it discloses the exact costs (0.5 XRP / 0.25 USDC), the settlement path (local facilitator; the t54 facilitator decodes the blob to bind the on-chain InvoiceID), and a precedence rule (when x_sol_payload is present the XRPL arguments are ignored). It stops short of describing failure/refund behavior or whether data is returned on partial payment.

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 correctly, with the purpose and the hard payment requirement in the first two lines before any detail. The Args block is well organized, though it partly duplicates schema field names and the indented formatting adds length without adding much beyond clarity.

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 payment-gated read with no annotations, no output schema, and no schema-level parameter descriptions, the definition covers the essentials an agent needs to attempt a call: cost, both payment paths, and their precedence. Remaining gaps are what the tool returns on success versus on unverifiable payment, and any retry/replay semantics for the invoice.

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 largely does: slug is given with an example, x_payment_signature is explained as a JSON string carrying both tx_hash and signedTxBlob (hex-encoded), and x_sol_payload is described as optional base64 of an x402 PaymentPayload. x_inv_id is only glossed as 'Invoice ID' with no format or source, and the description never states explicitly that only slug is required at the schema level.

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 specific verb+resource+scope: retrieving the latest data plus a freshness indicator for exactly one country. That is enough to distinguish it from list-oriented siblings like xrplme_list_countries, but it never explicitly contrasts itself with xrplme_get_country_schema or xrplme_get_country_status, which are close enough that an explicit distinction would help.

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 clearly signals the precondition (REQUIRES PAYMENT) and lays out two payment rails, which is a real usage constraint. However, it never says when to choose this tool over siblings such as get_country_status or get_country_schema, nor what happens if payment is omitted or fails. Usage is implied rather than guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses the exact cost per chain (0.1 XRP / 0.05 USDC), the required credential artifacts, the facilitator's decode-and-bind behavior, and the precedence rule that x_sol_payload causes XRPL args to be ignored. This is behavior an agent could not infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and payment requirement are front-loaded, then a structured Args block maps cleanly to the parameters. Slightly dense with per-chain formatting, but every line adds decision-relevant 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 paid, 4-param tool with no annotations and no output schema, the description covers the gating requirements thoroughly. It does not describe what the returned field schema looks like or its format, which is the only notable gap.

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 gets a concrete example, x_payment_signature is defined as a JSON string containing tx_hash and signedTxBlob (both required), x_inv_id is identified, and x_sol_payload is marked OPTIONAL with its encoding and effect.

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 the resource precisely ('Field schema for one country') and flags the payment requirement, which distinguishes it from the free-data siblings like xrplme_get_country_data. The verb is implicit (return/fetch) rather than stated, and it never explicitly contrasts itself with the other country tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: it tells you the tool costs money and how to pay, but not when to choose it over xrplme_get_country_data or xrplme_get_country_status. The rich payment guidance describes the mechanism, not the selection condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.

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.

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.