XRPLink

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

With no annotations, the description carries the full burden and does disclose the key behavioral trait: unauthenticated callers get a public receipt subset while the owning API key gets the full proof. That auth-tiered response shape is real value beyond structured fields. It omits error behavior for unknown UUIDs and whether status is mutable or cached.

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

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

Three short sentences, front-loaded with purpose before the auth-tier caveat. No filler, though the return-value sentences could be tightened into one clause.

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, and the description does the work of saying what comes back (public receipt subset vs. full proof). For a one-param read tool this is close to sufficient; only failure modes and status semantics are absent.

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 100% and the schema already documents the single 'id' parameter as the UUID returned from verify_xrp_payment. The description adds nothing beyond restating that it is a UUID, so the baseline of 3 applies.

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 and resource ('Get the current status of an attestation') and keys it to a UUID, which implicitly separates it from lookup_attestation_by_tx. It stops short of naming the sibling outright, so an agent must infer which lookup variant to pick.

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 implied by the 'by its UUID' framing, and the schema note ties it back to verify_xrp_payment, but the description never states when to prefer this over lookup_attestation_by_tx or verify_xrp_payment. No explicit exclusions or prerequisites are given.

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 disclosure burden. 'Get' plus zero parameters strongly implies a safe, side-effect-free read, and the returned content categories are listed, but nothing is said about auth requirements, caching, rate limits, or whether branding/config can vary per caller.

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?

A single sentence with no filler, front-loaded with the primary purpose and followed by the payload categories. Efficient, though it is one flat list rather than prioritized 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?

With no output schema, annotations, or parameters, the description is the only source of information, and it does enumerate the categories of data returned. It is sufficient for an agent to decide to call it, with only minor gaps (no mention of response shape or whether branding is optional).

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 schema has zero properties, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no input is 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?

Specific verb ('Get') plus a named resource ('XRPLink server information') and an enumeration of what is returned: network details, contract addresses, branding. That enumeration clearly separates it from the attestation/payment siblings, though the description never names those siblings explicitly.

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 implied by the nature of a zero-argument server-info call rather than stated. There is no guidance on when to prefer this over, say, checking attestation status, and no prerequisites 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.

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

With no annotations present, the description carries the full burden. It does disclose a genuinely useful behavioral trait beyond structured fields: the response is tiered by auth (unauthenticated gets a public receipt subset, the owning API key gets the full proof). It omits error behavior (unknown hash, malformed hash) and confirms nothing about idempotency or read-only nature explicitly, leaving gaps for a data-access tool with zero annotation coverage.

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

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

Three short sentences, zero waste, and the core action plus its key are front-loaded ahead of the auth-tiers detail. Nothing needs trimming.

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, and the description compensates by describing the two shapes of return data (public receipt subset vs. full proof). For a single-parameter read tool that is nearly complete, with only error/failure behavior left unaddressed.

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 100%, so the single txHash parameter is already fully documented (64 hex characters plus an example). The description's 'original' qualifier hints that the hash must be the originating transaction, but adds little beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 and resource ('Look up an attestation') with the lookup key ('by its original XRP transaction hash'). It is clear what the tool does, but it never distinguishes itself from the sibling get_attestation_status, which also retrieves attestation 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?

Implicitly guides usage by naming the lookup key (transaction hash), suggesting the agent should use this when it has a txHash. However, there is no explicit when-to-use vs. get_attestation_status or verify_xrp_payment, and no guidance for what to do when only an attestation ID or status is known.

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 thoroughly: it discloses quota costs, x402 payment challenge behavior (RLUSD first, then XRP), failure behavior (failed prepares do not consume quota), the meaning of a valid PAYMENT-SIGNATURE, and expected timing of 90–180 seconds. This is unusually rich behavioral 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?

The description is dense and front-loaded with the core action, followed by relevant constraints and billing details. It is appropriately sized for a tool with no annotations, though the billing sentences could be tightened slightly.

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 mutation-style tool with no annotations and no output schema, the description covers everything an agent needs: cost model, failure cases, payment challenge flow, timing, and the follow-up tool for status. Nothing critical 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 100%, so the single txHash parameter is fully documented in the schema including format and example. The description adds semantic meaning by specifying that it must be a native XRP Payment hash and that only the last 14 days are provable, which is beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Submit a native XRP Payment hash for FDC attestation on Flare.' It also distinguishes itself from the sibling get_attestation_status by directing status checks there. An agent can identify the exact operation 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?

It gives clear context: only Payments from the last 14 days can be proven, and status checks are free via get_attestation_status. It does not explicitly contrast with lookup_attestation_by_tx or get_attestation_by_round, but the main when-to-use guidance is present.

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