Probity Wallet Reputation

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

The annotation readOnlyHint=true already indicates a safe read operation, but the description adds valuable behavioral context beyond this: 'Costs zero credits', the output components (score, band, confidence, reason level diff, drivers), and the interpretive caveat about normal variation. This aligns with the annotation and adds transparency.

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 concise and front-loaded, with the core purpose in the first sentence. Each subsequent sentence adds distinct value (cost, use cases, output details, caveat). While it's slightly longer than necessary, there's no redundancy or fluff.

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 an output schema provided, the description doesn't need to detail return values, but it does outline the key outputs (score, band, confidence, reason diff, drivers). It also covers use cases and a caveat. Gaps include not stating prerequisites like 'runs must exist' or 'must be completed' explicitly, but 'completed screens' is mentioned. Overall, adequately complete for the tool's complexity.

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%, with both runIdA and runIdB already described as screeningId strings. The description reinforces this by mentioning 'screeningId' in the first sentence and clarifies they must be 'completed screens'. However, it doesn't add meaningful details beyond the schema's own parameter descriptions, so a baseline 3 is appropriate.

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 clearly states the tool's verb ('Compare'), resource ('two completed screens by their screeningId'), and purpose ('see what changed'). It also distinguishes itself from siblings by explaining the same-address vs different-address use cases, making it unique among the get_* and screen_address 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?

The description gives explicit context for when to use the tool: comparing two runs of the same address to understand score movement, or two different addresses for a side-by-side. It also cautions that small differences may be normal variation, which is a useful interpretive guideline. It doesn't explicitly name alternative tools but the context sufficiently implies the appropriate scenarios.

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 mark the tool as read-only and not open-world, and the description adds behavioral context: it costs zero credits and does not run a fresh screening. It also clarifies it retrieves the authenticated user's prior runs, which is useful beyond the annotations.

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 three tightly written sentences: it states the action and results, the intended use case, and the key cost/behavior difference. Every sentence earns its place; no filler or repetition.

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?

Even without an output schema, the description covers what the tool returns, when to use it, and how it differs from screen_address. For a simple read-only history lookup with two well-documented parameters, this is a complete and self-sufficient description.

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%, with both parameters (address and limit) already well-described. The top-level description does not add significant meaning beyond the schema, so the baseline of 3 is appropriate.

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 uses a specific verb ('Retrieve') and clearly identifies the resource ('prior screening runs for a specific Ethereum address') along with the exact data returned (reputation score, risk band, verdict flags, top reasons). It also distinguishes itself from the sibling tool screen_address by noting it is not a fresh screen.

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 explicitly states when to use the tool ('recall context for an already-screened address') and contrasts it with screen_address, which always runs a fresh screen. This gives clear guidance on selecting this tool over an obvious alternative.

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 readOnlyHint: true and openWorldHint: false, providing safety information. The description adds context that it is the authenticated user's own balance and 'current', which clarifies scope and temporality beyond what the annotations provide.

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 a single, clear sentence with no wasted words. It front-loads the key action and resource, making it immediately understandable.

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 tool with zero parameters, no output schema, and clear annotations, the description fully covers what the tool does and its scope. No additional information is necessary.

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?

With 0 parameters, the baseline is 4. The description correctly avoids mentioning parameters that don't exist, and the empty input schema confirms there are no parameter semantics to elaborate on.

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 clearly states the verb 'Returns', the resource 'credit balance', and the scope: 'the authenticated user's current credit balance'. This distinguishes it from sibling tools, which all relate to screening operations.

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 implies usage: when you need the authenticated user's current credit balance. There are no overlapping siblings (all siblings are about screening), so no explicit alternatives are needed. However, it does not explicitly say when not to use it.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds context about the authenticated user and recency of results, but does not disclose additional behaviors such as pagination or response format, so it only partially supplements the annotations.

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 a single concise sentence that conveys the core purpose without any filler words. It is well-structured and front-loaded with the action and resource.

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 read-only tool with one optional parameter and no output schema, the description is mostly complete. It states the scope (authenticated user) and the nature of the data (recent screening runs). The only minor gap is the lack of detail about the return format, but given the simplicity, this is acceptable.

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 input schema has 100% coverage for the single 'limit' parameter, with a clear description. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 clearly states the tool returns the authenticated user's recent screening runs. It uses a specific verb and resource, and distinguishes itself from sibling tools like get_address_screening_history by focusing on general screening runs rather than address-specific history.

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 provides no explicit guidance on when to use this tool versus alternatives. While the sibling tool names suggest some distinction, the description itself does not mention any exclusions or alternative tools, leaving the agent to infer context.

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?

Beyond the readOnlyHint annotation, the description discloses zero credit cost, background generation, the possibility of pending status, and retry guidance. This adds substantial behavioral context not available from annotations alone.

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 sentences, front-loaded with purpose, followed by cost and pending behavior. Every sentence adds value; no fluff or repetition.

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-parameter lookup tool with output schema and annotations, the description fully covers the retrieval purpose, cost, asynchronous generation, and retry behavior. Nothing essential 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% and the screeningId description already explains it is the rsr_... id from screen_address. The tool description reinforces the parameter's role ('completed screen') but adds limited new 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?

The description uses a specific verb ('Retrieve') and resource ('enhanced Probity review') and clearly identifies the target ('completed screen by its screeningId'). It distinguishes from sibling tools by focusing on the narrative output for a single screening rather than history or comparison.

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?

Provides clear context: the narrative is generated after screen_address returns and may briefly be pending, so retry shortly. It implicitly tells the agent when to use this tool (after screen_address, to fetch the narrative). Does not explicitly name alternatives, but the context is strong enough for a 4.

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?

The description discloses a per-use credit cost ('Costs 1 credit'), the background generation of an enhanced review, and that the returned score is signed — all beyond the annotations. It also names the exact returned fields and the follow-up call, giving the agent a clear behavioral model.

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 organized front-loading the purpose, then cost, return payload, background behavior, and usage guidance. The sentence enumerating return values is somewhat lengthy but arguably valuable for an agent; it stays on-topic with no fluff.

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 a single parameter and high schema coverage, the description covers cost, output characteristics, background process, and linkage to the narrative tool. It fully equips an agent to decide whether to call this tool and what to do with the result, making it 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?

The single parameter 'address' is fully described in the schema with accepted formats. The description merely restates 'Ethereum address or .eth ENS name' without adding new semantic detail, 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?

The description opens with 'Screen an Ethereum address or .eth ENS name for on-chain reputation risk,' using a specific verb and resource that clearly differentiates from siblings like get_screening_narrative and get_screening_history. It immediately conveys the tool's core function.

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 provides direct usage context by stating 'Use the score, band, and sanctioned flag to gate pre-trade or payout flows,' and points to get_screening_narrative for fetching the background-enhanced review. This implicitly distinguishes it from the narrative tool, though it doesn't explicitly list when-not-to-use scenarios or compare with other screening history tools.

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