nulucre-wallet-reputation

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds meaningful context: it is a free endpoint requiring no payment, and it discloses the error-return convention ('Error: ...' when unreachable). It stops short of stating rate limits or timeout 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?

Front-loads the core purpose and scoping in the first two sentences, then uses labelled sections. The 'Args: none' line and the example block are mildly redundant, but the structure is easy to scan and every block carries some signal.

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 in the structured data, the description compensates by documenting the return shape (status/service fields) and the error path. Combined with annotations covering safety, an agent has everything needed to call and interpret this zero-arg tool.

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 zero parameters, which sets the baseline at 4. The description explicitly confirms 'Args: none', matching the empty schema and additionalProperties:false, so nothing is ambiguous.

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

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

States a specific verb and resource ('Check whether the live Nulucre reputation oracle service is online'), and the sibling tools are all wallet-scoring calls, so the health-check role is unmistakable. An agent can differentiate this from the scoring tools without opening any 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?

Clearly says to use it to verify reachability before relying on Nulucre for wallet scoring or for uptime monitoring, and the example section reinforces the trigger ('Is Nulucre up?'). It doesn't name an explicit 'when not to use' alternative, but given the siblings are scoring tools rather than substitutes, the context is unambiguous.

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?

Annotations already establish read-only/idempotent/non-destructive, and the description goes well beyond them: it names the upstream data sources (Etherscan, Moralis, Alchemy, Ankr), explains what the score is derived from, discloses that signing is a higher-cost endpoint verified via a public JWKS, and documents quota exhaustion 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?

Front-loaded with the core purpose, then cleanly sectioned into Args, Returns, Examples, and Error Handling, all of which earn their place. It is somewhat long and the Args block partially repeats the input schema, costing a point.

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 compensates by documenting the full return shape including score bands, breakdown, chains, timestamp, and conditional signature field. Combined with chain coverage and error handling, an agent has everything needed to call and interpret the tool.

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: it explains that signed=true enables independent verification through Nulucre's JWKS endpoint, and restates the price/quota implication behind the flag. The wallet and response_format entries largely mirror 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?

States a specific verb and resource ('Get a 0-100 trust score for an EVM wallet address') with scope (81+ chains) and the oracle's data provenance. It explicitly delineates itself from sibling tools by naming the Stellar counterpart in the exclusions.

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 explicit when-to-use context ('assess counterparty risk before an agent interacts with or pays an EVM wallet'), concrete trigger examples, and a when-not-to-use clause that routes Stellar addresses to nulucre_get_stellar_wallet_score. Nothing 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?

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's extra disclosures carry the weight: real-time OFAC/UN/EU sanctions screening and, importantly, that the call is billed via x402 USDC micropayments. The payment requirement is a genuine behavioral trait absent from annotations, though it does not cover rate limits or failure/latency 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?

Five short sentences, front-loaded with the core value proposition and then the signals, screening, usage trigger, and billing model. Every sentence is informative, though the signal enumeration could be trimmed if brevity mattered more than completeness.

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 does the work of explaining what the score means (0-100), how it is derived (7 named RPC signals), and what extra coverage exists (sanctions screening) — enough for an agent to act correctly. Minor gaps remain around latency, failure handling, and how the signed variant changes the response.

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 address, signed, and response_format fully; the baseline is therefore 3. The description adds no parameter-level detail (it never mentions the signed-ECDSA option or the markdown/json output choice), so it does not exceed 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?

States a specific verb and resource ('Get a 0-100 trust score for a Solana wallet address') and clearly scopes it to Solana, which is exactly what distinguishes it from the EVM, Stellar, and XRPL siblings. It even names the scoring methodology and provider, so an agent can identify 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?

Gives a clear usage trigger ('Use before paying or interacting with any Solana wallet'), which tells the agent the decision context. It does not, however, name an alternative or state when not to use it (e.g., prefer a cached/local check, or the sibling score tool for non-Solana chains), leaving the routing 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the eight signal inputs, the sanctions lists screened (OFAC SDN, EU, UN), the deterministic BLACKLISTED=0 behavior, the higher-cost nature of the signed endpoint, and error handling for invalid addresses and exhausted free quota. That is exactly the behavioral disclosure an agent needs before calling.

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 and organized into Args/Returns/Examples/Error Handling sections, which is easy for an agent to scan. It is on the long side, and the g_address phrasing duplicates the schema's pattern description almost verbatim, which is mild redundancy.

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 carries the return-value burden and does so with a full JSON shape including status enum values and the conditional signature field. Combined with error handling and examples, nothing material is missing for correct invocation.

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: 'signed' is tied to independent verification via the public JWKS endpoint and flagged as a higher-cost path, and the markdown-vs-json tradeoff is spelled out. The g_address explanation largely restates the schema pattern, keeping it below a 5.

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 a specific verb and resource ('Get a 0-100 trust score for a Stellar wallet address') and immediately scopes it to the Stellar network, explicitly stating 'No EVM data is used.' It also names the sibling to use instead for EVM addresses, so an agent can distinguish it from nulucre_get_evm_wallet_score and nulucre_get_xrpl_wallet_score without opening any 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 concrete when-to-use conditions ('before executing a payment, approving a swap counterparty, or evaluating a new account') and a when-not-to-use clause routing EVM addresses to nulucre_get_evm_wallet_score. The examples section reinforces both positive and negative triggers.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuine behavioral context beyond that: the 7 scoring signals and real-time OFAC/UN/EU sanctions screening tell the agent what the result represents. It omits return format, latency, and any rate-limit/auth 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?

Four tight sentences with the core purpose and scoring basis front-loaded. No filler, though the signal list is dense and 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?

For a single-address lookup with no output schema and full schema coverage, the description adequately explains what the score is composed of and when to call it. Only the returned structure/format is left unaddressed, which is minor here.

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 r_address, signed, and response_format. The description adds no parameter-level meaning (e.g., it never explains the signed or response_format options), 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 (get) and resource (0-100 trust score) scoped to XRPL wallet addresses. The chain reference cleanly distinguishes it from the EVM and Stellar siblings without needing their schemas.

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?

"Use before paying or interacting with any XRPL wallet" gives clear actionable context for invocation. It does not explicitly name the sibling alternatives (get_evm_wallet_score / get_stellar_wallet_score) or state when NOT to use it, so it stops short of a 5.

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