UXUS Agent Services: wallet lookup, entity labels, caller ID

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 reveals the decision policy (BLOCK on sanctioned/drainer/phishing/scam/mixer or BLOCK risk verdict, SCREEN as default for unknowns), the return components (reasons[] plus a confidence flag), and that the call is free. It does not explicitly state the call is read-only/no-side-effect, which is the only notable 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-loads the core question, then context, then behavior, then params – a sensible order with no filler. The 'Params:' clause duplicates the schema, which is the one economical ding.

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, the description must cover returns and does: verdict enum, reasons[], and confidence flag, plus the decision thresholds behind them. For a two-parameter screening call this is close to complete, missing only explicit read-only/side-effect framing and latency or rate-limit expectations.

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% and the schema already states 'default base' and '0x EVM address. Required.', so the description's param sentence largely restates structured data. Baseline 3 applies; it adds no format, validation, or chaining detail 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?

Opens with a concrete decision question ('Should this wallet be answered?') and names the resource (EVM wallet) plus the exact verdicts it produces, which tells the agent this is a composite risk/attribution decision tool rather than a raw lookup. It differentiates implicitly from lookup_wallet/check_entity by describing the composed signals, but never names a sibling outright.

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?

Gives a clear domain trigger: 'For wallet messaging (XMTP, Push), which has no spam filter', so the agent knows the scenario this is built for. It stops short of naming when to prefer check_entity or lookup_wallet instead, so sibling routing 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.

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

With no annotations, the description carries the full load and does well: it names the data provenance (OFAC, ScamSniffer, MEW, eth-labels, curated Base/Tornado sets), defines the sanctioned-vs-flagged distinction against the OFAC SDN list, and states 'never guesses' and 'Free'. It stops short of stating read-only status explicitly, auth requirements, rate limits, or caching, so a top score is not earned.

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 core distinction, then params and return shape; every clause carries information (enum values, provenance, semantics). It is dense and slightly run-on, with the source list and category list competing for attention, but not padded.

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?

There is no output schema, so the description fully compensates by enumerating the return object ({ address, chain, is_known, label, category }) and spelling out all category values, including the edge-case semantics of 'sanctioned' vs 'flagged' and 'unknown'. For a 2-parameter lookup tool this is 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 100% and the description only restates the same facts — address format/requiredness and chain default/alternatives. It adds no syntax, normalization, or validation detail beyond the schema, so the baseline 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+resource ('Entity attribution — what IS this address') and immediately scopes it against the ownership-style siblings with 'not who owns it', which separates it from caller_id and lookup_wallet. An agent can pick this tool 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 contrast clause 'what IS this address, not who owns it' effectively routes the agent between this and the identity/ownership tools. There is no explicit when-not or prerequisite statement (e.g., that only EVM addresses on base/ethereum are supported), but the usage context is clear.

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 a reasonable job: it discloses that there are no inputs, what the response keys are, and that the call is free (no credit cost). It omits any statement about rate limits, auth requirements, or failure semantics, but for a trivial read-only probe this is largely covered.

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 compact sentences, purpose first, then inputs and return shape. Nothing is padded and the most decision-relevant information is front-loaded.

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?

There is no output schema, but the description supplies the return shape ({ ok, service, time, upstream }) and the meaning of the tool, which is everything an agent needs for a parameterless diagnostic endpoint.

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?

Zero parameters, so the baseline is 4. The description explicitly says 'No parameters,' which matches the empty schema and confirms there is nothing to infer.

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 ('Service health check') and adds the concrete purpose: confirming the uxus.finance API is reachable. That is unmistakably distinct from the sibling lookup/resolution/scrape tools, so an agent can select it 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?

Usage is implied by 'confirms the uxus.finance API is reachable,' which tells the agent this is a connectivity/diagnostic probe. However, it never states when to prefer this over simply attempting a real call, nor any exclusions or alternatives.

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 behavioral burden and does so: paid x402 call at $0.02 USDC on Base against GET /api/lending/grade, it returns a payment resource rather than a result, and it is not yet live so it returns available:false with no charge. It also enumerates the inputs feeding the grade (size, utilization, first-loss cover ratio, late/impaired/defaulted loans, unrealized loss, realized yield).

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 purpose and scope, then layered caveats (paid call, returns payment resource, not live yet, params). Dense but each clause is load-bearing; the final params sentence is the only mildly redundant part given the schema.

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 specifying what a call produces (a payment resource), the concrete not-live response shape (available:false, 503, no charge), and the grading inputs. An agent has everything needed to decide and invoke 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 100%, so both parameters are already fully documented, including the 64-hex pattern and the 'detected when omitted' note for type. The description merely restates id as required and type as optional, adding no syntax or format detail beyond the schema; baseline 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 resource and output (A-F risk grade for one XRP Ledger lending vault or loan broker) and the exact input domain (64-hex Vault or LoanBroker ID). It also explicitly distinguishes itself from an adjacent concept ('Not a credit rating') and from what it is not (a computation tool).

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?

Explicitly tells the agent when this applies (grading a single vault or broker from on-ledger data), what it actually does on invocation (returns the payment resource, does not compute the grade), and the failure mode to expect (available:false / 503 upstream, no charge) because the protocol is not live. No sibling tool could be mistaken for it, so no alternative-routing sentence is needed.

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 well: it discloses cost ('Free'), that chain/address type is auto-detected from format, and the exact normalized return envelope. It omits auth requirements, rate limits, and error behavior, so it is strong but not exhaustive.

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 purpose, then cleanly segmented into Params and Returns sections; every clause carries information. It is dense and slightly telegraphic, but no sentence is wasted.

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?

Covers the essentials an agent needs to call correctly: inputs, auto-detection behavior, cost, and the returned fields in lieu of an output schema. Missing only secondary details such as failure modes or rate limits.

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 baseline is 3, but the description adds real meaning beyond the schema by explaining that the two address formats are auto-detected and that 'chain' is only a hint for EVM history rather than a required selector. That clarifies parameter interaction rather than merely restating names.

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 ('address lookup') and scopes it to two concrete address families (EVM 0x, XRPL r-addresses) with auto-detection. An agent can distinguish this from siblings like check_entity or resolve_name 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?

Gives clear usage context ('fast first-pass check on a counterparty wallet') and marks it as free, which helps an agent choose it for cheap preliminary screening. It does not, however, name the sibling tools it should be preferred over or excluded in favor of, leaving that inference to the agent.

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 behavioral burden well: it discloses reverse records are forward-verified to prevent name spoofing, that XRPL .xrp names are detected but resolved:false, and that the call is free. It does not mention auth requirements or rate limits, but the safety-relevant behaviors are covered.

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 core purpose, then param, then behavioral caveats. Every sentence earns its place, though the parameter restatement is slightly redundant with the schema and the return-field list makes it 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?

For a single-param resolution tool with no output schema, the description compensates by enumerating the return shape ({ query, kind, namespace, chain, resolved, address, name, sources }) and the XRPL failure case. Error handling and latency are unaddressed but the core contract is 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 coverage is 100%, so the schema already documents q. The description still adds value by enumerating the accepted input forms (ENS/Basename name, EVM 0x address, XRPL r-address) and the auto-detection behavior that determines how q is interpreted.

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 ('Bidirectional name <-> address resolution for ENS (name.eth) and Basenames (name.base.eth)') and names the parameter. An agent can immediately distinguish this from lookup_wallet or caller_id because the ENS/Basename and XRPL scope is explicit.

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 context is implied by 'Auto-detects direction' plus the XRPL caveat, so an agent knows the tool handles both forward and reverse lookups. However, it never says when to prefer this over siblings like lookup_wallet, nor any when-not conditions beyond the XRPL unresolved note.

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 well: it discloses the payment requirement ($0.01 USDC on Base at GET /api/scrape) and the critical contract that it returns a payment resource rather than the page content. It stops short of describing the shape of that payment resource or what happens on payment failure.

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 purpose and the critical payment/return caveat, then a compact param list. The param recitation is largely redundant with the schema, which is the only wasted space.

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 stating what is returned (the payment resource, not the page) and how to pay. For a 3-param tool this is nearly complete, though the mechanics of completing the x402 payment are left to the agent to discover.

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 schema already documents url, format and max_chars including defaults and the max bound. The description restates these but adds no syntax or format detail beyond structured fields, so baseline 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?

The description names the specific resource ('any web page') and the output form ('clean, LLM-ready markdown, text or html'), and — crucially — clarifies the non-obvious twist that this tool does not fetch the page but returns the payment resource. That lets an agent distinguish it from siblings like search_web 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 states the context implicitly (you want page content, and it's a paid x402 call), but never states when to prefer this over search_web or any alternative, nor any prerequisites beyond the price. Usage is inferable but not routed.

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 behavioral burden, and it does so well: it discloses the payment model ($0.01 USDC on Base), the endpoint (GET /api/search), and the non-obvious fact that the tool returns a payment resource instead of search results. It omits failure modes, payment-resource lifetime, and post-payment flow, so it falls short of exhaustive.

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, then the payment mechanic, then parameters — a sensible order with no fluff. The trailing parameter recap is largely redundant against a 100%-covered schema, which is the only thing that keeps it from a 5.

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 6-parameter tool with no annotations and no output schema, the description supplies the essential missing context: what it returns (a payment resource, not results) and the cost/mechanism. It stops short of explaining how to complete the call or what a successful response looks like, leaving a modest 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 100%, so the schema already documents every parameter including defaults, ranges, and optionality. The description merely restates query/count/country/language/page/device with no added syntax, format, or interaction detail, matching the baseline for fully-covered schemas.

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 ("Live web search") and enumerates the result scope: ranked results plus answer box, knowledge graph, people-also-ask and related searches. Critically, it also pins down the tool's odd role — it returns the payment resource rather than executing the search — which separates it from a naive search or from a page-fetch sibling like scrape_url.

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 the context an agent needs to decide whether to invoke: this is a PAID x402 call costing $0.01 USDC on Base, so it should be reserved for cases where live search justifies the spend. There is no explicit naming of alternatives or when-not-to-use, keeping it below a 5.

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 disclosure burden and does so well: it states the tool is a paid x402 call, names the exact price, asset and chain, explains that the tool returns the payment resource rather than the computed grade, and discloses the disclaimer ('general information, not advice; the products graded pay nothing'). It also enumerates the returned fields (rate, size, lockup, withdrawal terms, custody, chain, age, audits, data source timestamp, grading rules). This is unusually rich behavioral context for a no-annotation tool.

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 caveat (returns a payment resource, does not compute the grade) are front-loaded, which is good, but the middle is a dense run-on enumerating product families and return fields. It is information-dense rather than padded, yet a few clauses (the long product list) could be trimmed without loss.

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?

There is no output schema and no annotations, so the description must cover everything — and it largely does, specifying cost, payment mechanics, return contents, id discovery, and disclaimer. The only gap is that it does not explain what happens on payment failure or how the agent should complete the x402 payment flow after receiving the resource.

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 baseline is 3. The description restates 'id (option id, required)' and points to the free options endpoint for obtaining a value, but the schema already contains that same URL and example. It adds no format or constraint detail beyond what the schema provides.

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 concrete verb+resource: it produces an 'A-F risk grade for one way to earn on XRP or RLUSD' from the XRP Yield Desk, and it names the covered product categories (XRPL AMM pools, Doppler vaults, Firelight stXRP, exchange earn programs). It also discloses a non-obvious twist — the tool returns the payment resource rather than computing the grade — which helps an agent avoid misreading the name. It stops short of explicitly contrasting itself with the sibling lending_grade, so it is clear but not fully sibling-differentiating.

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 a clear prerequisite (find ids for free at xrplhub.io/api/yield/options) and full cost context ($0.02 USDC on Base, x402 paid call). It frames when the tool is relevant (yield/earn products) without stating when it should be avoided or how it compares to lending_grade. Clear context, no exclusions.

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