mcp-server

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

The description extensively covers behavioral traits beyond annotations: blockchain detection, balance scanning, retry mechanism, cancelled-call handling, post-verify re-check, EVM chain nuances, and zero-balance note. No contradictions with 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 comprehensive but somewhat lengthy; however, it is well-structured with sections and front-loaded purpose. Each sentence serves a purpose given the tool's complexity.

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 tool's role and output schema existence, the description covers all relevant scenarios: retry, cancelled calls, post-verify checks, EVM restrictions, and zero-balance hints. It leaves no significant 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?

The single 'address' parameter is well-described in schema (100% coverage). The description adds context about address identification, EVM processing, and not using wallet_id, which enhances 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 clearly states the tool submits a public wallet address for verification, detects blockchain, scans balances, and returns verification options. It distinguishes itself from siblings like remove_wallet and verify_wallet_signature.

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 explicit when-to-use (adding wallet, retry for failed/unverified), when-not-to-use (already verified, specific chains for dust transfer), and alternatives (get_wallet_summary post-verification). It also includes guidance on cancelled calls and EVM chain limitations.

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?

Discloses return behavior (download link valid 30 days, inline widget), cancellation handling, and notes that the widget handles presentation so agent need not repeat URL. No contradiction with annotations; provides context beyond readOnlyHint=false.

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?

Well-structured with clear sections (CANCELLED-CALL HANDLING, CEILING). Every sentence adds value; no redundant information. Front-loaded with core purpose.

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?

Description covers all necessary aspects: prerequisites, return format, edge cases (cancellation, ceiling constraint), and interaction with sibling tools. Fully compensates for any lack of output schema details.

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%, baseline 3. Description adds crucial constraint for 'amount' parameter: must be ≤ pof_ceiling_usd from get_wallet_summary, and warns against using total_verified_usd. This goes beyond schema. Currency parameter already well-defined.

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?

Clearly states the tool generates a Proof of Funds letter (PDF) for the authenticated user, using specific verb 'Generate' and resource 'Proof of Funds letter (PDF)'. Distinguishes from sibling tools by specifying prerequisites and behavior not shared by other 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?

Provides explicit prerequisites: required identity verification and at least one verified wallet. Gives clear ceiling rule to use pof_ceiling_usd from get_wallet_summary and advises calling that tool if unsure. Also covers cancellation handling with retry logic.

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, idempotentHint, destructiveHint. The description adds useful context about the scope: it returns wallet count but not individual details, and confirms it answers readiness questions. No contradictions with 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?

Two sentences with no redundancy. The first sentence states what it does; the second provides usage guidance. Every sentence earns its place.

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 no parameters, comprehensive annotations, and an output schema, the description is fully sufficient. It clearly defines the tool's purpose and limits, leaving no gaps for an AI agent.

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 params, 100% coverage), so the description need not add parameter details. The description adds value by explaining what the tool returns, compensating for the lack of parameters.

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 it returns a high-level account overview including identity verification state, wallet count (not details), and Proof of Funds eligibility. It explicitly distinguishes from the sibling tool get_wallet_summary by stating what it does not provide.

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 explicitly states when to use this tool ('is my account ready?' questions) and when not to (wallet-specific requests), providing the alternative tool get_wallet_summary. This gives clear guidance to the AI 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 readOnlyHint, idempotentHint true; description adds behavioral details: returns up to 20 matches, returns categories on no match. No contradictions.

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 sentences, front-loaded with purpose, no extraneous words. Efficient and clear.

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 search tool with output schema, description fully explains purpose, usage, edge cases, and limits. No 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 coverage is 100%, so baseline is 3. Description reinforces parameter roles and adds context about returning categories on no match, which goes beyond 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 clearly states the tool searches FAQ by keyword and/or category, and distinguishes from siblings by specifying it is for RealOpen-specific questions, not general knowledge.

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 states when to use (user asks specific question about RealOpen process) and provides behavior on no match (returns category list). Advises preferring this over guessing.

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. Description adds that it returns live fee schedule and worked examples, providing behavioral context beyond 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?

Two concise sentences with no waste, front-loaded with purpose and clear use cases.

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 zero parameters and the existence of an output schema, the description sufficiently explains the tool's output and usage. No 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?

No parameters to describe; baseline 4 applies. Description adds no param info, but none 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?

Description clearly states the verb 'Return' and the resource 'RealOpen's current pricing and fee breakdown with worked examples'. It explicitly lists triggering user queries, distinguishing it from sibling tools that cover other topics.

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 explicit usage guidance: 'Use this whenever a user asks about RealOpen cost, fees, commissions, or total out-of-pocket'. Also states it supersedes model estimates, establishing authority.

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, idempotentHint=true, and destructiveHint=false. The description adds value by stating the content is 'maintained by RealOpen and is more current than general model knowledge', which is a behavioral trait beyond the annotations. No contradiction found.

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, no wasted words, front-loaded with the core purpose. Every sentence earns its place by providing clear action, usage guidance, and authority context.

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?

The tool has one parameter with a default and enum values, and an output schema exists. The description fully explains what the tool returns and how to filter by perspective. Given the simplicity of the tool, the description is completely adequate.

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% for the single parameter, so baseline is 3. The description adds meaning by listing the perspectives in plain language ('buyer step-by-step, agent/seller-side, or high-level overview') which maps directly to the enum values and enhances understanding.

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 'RealOpen's canonical explanation of how a crypto-to-real-estate transaction works'. It uses a specific verb ('Return') and resource ('explanation'), and distinguishes from sibling tools by focusing on the end-to-end process, timing, and flow.

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 explicitly states when to use the tool ('to answer any question about RealOpen's process, timing, or end-to-end flow') and provides a preference rule ('always prefer it over guessing'). It does not explicitly state when not to use it, but the context from siblings makes it clear this is for process explanations.

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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds context that the ref_id is resolved server-side, so the model doesn't need to ask. This adds value beyond the annotations. No contradictions.

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 two sentences, both informative and front-loaded. No unnecessary words. Every sentence earns its place.

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 tool's simplicity (one optional param, output schema exists), the description covers purpose, usage guidelines, and key behavioral details. It is fully complete for an agent to use 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 coverage is 100% with a description for the 'path' parameter. The description does not add extra meaning beyond what the schema already provides. 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 verb 'Construct' and the resource 'tracked referral URL pointing at a realopen.com page.' It distinguishes itself from sibling tools by specifying its use for marketing content, recommendations, or sign-up suggestions.

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 explicitly tells when to use the tool: 'Use this whenever you produce marketing content, recommendations, or sign-up suggestions.' It also explains that the user's ref_id is resolved server-side, guiding the model not to ask for it. However, it does not include when not to use it or mention 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by clarifying the dynamic nature ('current') and listing specific data categories. No contradictions.

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, zero fluff. The key action and usage guidance are front-loaded. Every sentence earns its place.

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 zero-parameter tool with an output schema (context signal), the description fully captures what the tool returns. It specifies the domains covered and gives examples, making it complete for agent decision-making.

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?

No parameters exist, so schema coverage is 100%. The description doesn't need to add parameter details; baseline 4 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 geographic coverage, supported property types, and international availability. It uses specific verbs ('Return') and resource categories, distinguishing it from sibling tools that deal with wallets, FAQs, and other functions.

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 to use this tool: 'whenever a user asks whether RealOpen operates in a particular state, country, or property type'. This provides clear decision criteria and examples.

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, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds that snippets are 'copy-ready posts written by RealOpen's marketing team' and 'pre-approved', which is useful behavioral context 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 two sentences, front-loaded with purpose and usage, then a brief enumeration of filters and content. Every sentence adds value with no wasted words.

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 read-only query tool with no required parameters and an existing output schema, the description explains what each snippet includes (body text, tags, share title, preview), providing sufficient context for selection. No 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 100% with clear descriptions for all 5 parameters. The description summarizes filters as 'Filter by platform, tone, tag, attached asset, or keyword', which adds no new meaning beyond the schema. 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 finds 'pre-approved RealOpen social-media snippets' with a specific verb 'find' and resource 'snippets'. It distinguishes from sibling tools like get_faq and get_how_it_works by focusing on social-media content.

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 explicitly says 'Use this when a user asks for ready-to-post content or needs inspiration grounded in approved brand voice', providing clear context. It does not explicitly state when not to use, but the sibling tool list implies 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds crucial behavioral context: returns a 'current list' that is 'live' and 'maintained by RealOpen', warning that model knowledge may be stale. No contradictions.

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 concise sentences with zero waste. First sentence states purpose and resource, second provides usage guidance and source-of-truth context. Front-loaded with key 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?

Complete for a no-parameter, read-only tool with annotations and output schema. Covers purpose, usage, and behavioral nuance (live list, stale model knowledge). No 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?

No parameters; schema coverage is 100%. Baseline score of 4 for zero-parameter tools. Description adds no parameter details but none are 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?

Clearly states verb 'Return the current list' and resource 'cryptocurrencies, blockchains, and stablecoins accepted by RealOpen for real-estate purchases'. Distinguishes from siblings by being the sole tool for supported crypto list, and explicitly ties to use case 'answer can I pay with X?'.

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 says when to use: 'to answer can I pay with X? or whenever a user needs the live list'. Also positions itself as source of truth over model knowledge, effectively telling the agent to prefer it over stale information.

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, idempotentHint, destructiveHint, so safety is clear. The description adds crucial behavioral details: interpretation of three distinct monetary values (pof_ceiling_usd, total_verified_usd, sum total_usd), explanation of linked_addresses, and zero-balance warning. This goes well beyond 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 lengthy but front-loaded with purpose. Every paragraph adds necessary detail (three numbers, zero-balance note, linked addresses). It could be slightly more concise, but the structure (heading-like paragraphs) aids readability.

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 no parameters, presence of annotations, and output schema being present (though not shown), the description covers all aspects: return structure, interpretation of numbers, edge cases (zero balance, linked addresses), and presentation advice. It is fully self-contained for agent usage.

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 no parameters (empty schema, 100% coverage), so the baseline is 4. The description does not need to explain parameters; it still adds value by describing what the output contains and how to interpret it.

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 explicitly states when to call this tool ('whenever the user asks for a wallet summary...'), provides specific triggers (wallet list, balances, verified holdings, POF ceiling), and clearly distinguishes it from siblings by giving the precise use case. It also names the resource ('wallets for the authenticated user') and verb ('Returns').

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 clear context on when to use (user asks for wallet summary, etc.) and includes presentation guidance (summarize counts, let widget handle details). It also hints at post-usage actions (suggest POF amounts). However, it does not explicitly exclude usage for other sibling tools or state when not to use this tool.

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 annotations already indicate idempotentHint=true and destructiveHint=false, so the description need not repeat those. The description adds minimal behavioral context beyond stating the action, which is adequate but not extra.

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 two sentences, front-loaded with the key action, and contains no unnecessary information. Every word earns its place.

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 logout tool with no parameters and an output schema available, the description is sufficient. It covers the purpose and usage without needing to explain return values.

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 zero parameters, and schema description coverage is 100%, so the baseline is 4. The description does not need to add parameter semantics since there are none.

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 action ('sign out') and the resource ('RealOpen MCP session'), providing good purpose clarity. No sibling tool does this, so differentiation is not needed.

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 explicitly states when to use the tool ('when the user wants to switch accounts or disconnect'), providing clear usage context. No alternatives or exclusions are mentioned, but none are necessary given the tool's unique role.

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 annotations (readOnlyHint=false, idempotentHint=true), the description explains that if fetch returns empty or no USD values, existing balance is preserved (status=no_change). It also covers linked addresses and zero-balance hints, providing 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?

Though lengthy, every sentence adds value. It is front-loaded with main purpose, then usage guidelines, then edge cases. No fluff, well-structured.

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 complexity of on-chain balance fetching, zero-balance edge cases, and linked addresses, the description is thorough. It covers return behavior, presentation guidance, and edge cases. Output schema exists but description still provides essential context.

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 100% schema coverage, the description adds crucial context for wallet_id: it is an internal UUID not to be shown to the user, and the agent should look it up from the address mentioned. This adds significant meaning 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 clearly states it re-fetches on-chain asset balances for an existing wallet and updates the stored record. It differentiates from siblings like refresh_wallet_verification and get_wallet_summary by focusing specifically on balance refresh.

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 when to use: 'when the user says their balance looks stale, wrong, or zero after a recent on-chain change.' Also provides safeguards for empty results and zero-balance handling, guiding the agent on when not to assume empty.

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 indicate non-read-only, non-destructive. Description adds detailed behavioral context: it renders an inline Verify Wallet widget, internal calls to verify_wallet_signature/transfer may not produce visible follow-up, and the output is stale after widget use. No contradictions with 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 long but well-structured with a clear front-loaded purpose and a separate post-verification section. Every sentence adds necessary information, though minor trimming might be possible.

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 tool with annotations and output schema, the description covers return shape, widget behavior, multi-asset support, and post-verification procedure. No gaps remain.

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% with a clear description for wallet_id. The tool description adds value by explaining the source of wallet_id and instructing not to show or ask for it. This goes beyond the schema alone.

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 explicitly states the tool regenerates verification challenges for an unverified wallet, with specific use cases (failed verification, fresh challenge needed). It distinguishes from siblings like verify_wallet_signature/transfer and add_wallet by noting it returns the same shape as add_wallet.

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 when-to-use scenarios and includes a critical POST-VERIFY RE-CHECK section advising to call get_wallet_summary after the widget is used, and warns about potential lack of visible follow-up. This guides the agent on proper usage and 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?

Beyond annotations (destructiveHint=true), the description specifies exact deletions (wallet record, verification status, balance history) and the effect on the Proof of Funds ceiling. Adds valuable behavioral context without contradiction.

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 concise paragraphs front-load the purpose and destructive nature, then give precise usage instructions. Every sentence adds value with no 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?

Covers all essential aspects: prerequisite user confirmation, identifier referencing rules, side effects, and impact on other features. Output schema exists, so return value explanation unnecessary.

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 description adds crucial meaning beyond the schema: the wallet_id is an internal UUID that must not be shown to the user; it should be looked up from the address the user provided. This compensates for the single parameter and avoids misuse.

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 permanently removes a wallet, specifying what is deleted (record, verification status, balance history). It is distinct from sibling tools like add_wallet or verify_wallet_signature.

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 explicit guidance on when to use and what to do before calling: confirm with user by address, get explicit confirmation, and never show the wallet_id UUID. Also warns about impact on Proof of Funds ceiling. Does not explicitly mention alternatives but 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds return format details (up to 20 assets, URLs, captions, tags, inline thumbnails for first five), providing value beyond 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?

Two sentences, front-loaded with purpose, followed by usage and return information. No wasted words.

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 tool's complexity (4 optional params, output schema exists), the description covers scope, filtering options, and return structure including limit and thumbnail preview. Complete for a search 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 description coverage is 100%, so the schema already documents each parameter. The description mentions filtering by keyword, category, tags, or file type, but does not add significant new meaning beyond what's in 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 clearly states the tool searches RealOpen's library of approved affiliate marketing assets, listing specific asset types (flyers, social graphics, etc.). It distinguishes from sibling tools (no other asset search tools present).

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 explicit when to use: 'when a user asks for existing RealOpen marketing material they can download or share'. Does not explicitly state when not to use or mention alternatives, but 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?

The description adds behavioral context beyond annotations by explaining that new sessions are created for incomplete/denied/expired prior sessions and that a URL is returned for browser opening. Annotations indicate non-idempotent and non-destructive, which aligns with description. No contradictions.

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 two sentences long, front-loads the core purpose, and every sentence adds value. No unnecessary words.

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?

The description covers purpose, session behavior, and return value (URL). With an output schema existing (though not detailed), it provides sufficient context for a 2-parameter tool. Minor gap: no mention of failure scenarios or URL expiry.

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% description coverage, so the schema already documents the parameters. The description adds no additional meaning beyond the schema for the two boolean parameters, earning the baseline score of 3.

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 starts or restarts identity verification (KYC). It specifies the action ('Start or restart') and the resource ('identity verification'), and distinguishes from sibling tools focused on wallet verification or other account actions.

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 implicitly indicates when to use the tool: to initiate or re-initiate KYC after an incomplete, denied, or expired session. However, it does not explicitly compare with alternatives like 'refresh_wallet_verification' or provide when-not-to-use guidance.

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 are minimal (no destructive/readOnly hints), but description adds rich behavioral context: the signature must be the full hash from signing the verification message, the widget handles the call automatically if visible, and wallet_id lookup procedure. No contradictions.

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?

Description is relatively long but every sentence adds value. It is front-loaded with purpose and then details usage. Could be slightly trimmed, but the detail is necessary for correct invocation.

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 presence of output schema, description covers prerequisites, two invocation paths, and common errors. It addresses the full context needed for accurate tool selection and 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 covers both parameters with 100% coverage. Description adds crucial meaning: wallet_id must be looked up from prior tool responses and never shown to user; signature requires the full hash from wallet.

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 'Submit a signed message to verify wallet ownership' and specifies the exact verification message from add_wallet. It distinguishes from sibling tools like verify_wallet_transfer and mentions related 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?

Provides explicit when-to-use scenarios with two clear paths (widget visible vs. no widget) and when-not-to-use (do not respond with 'I'd need to work out the wallet_id...'). References sibling tools and gives step-by-step instructions.

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 indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds behavioral context: asset detection auto-matches across accepted assets, asset_symbol is an audit hint, and the widget can call the tool autonomously. However, it doesn't explicitly state that the tool mutates wallet verification state, which is implied but could be clearer.

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 lengthy but well-structured with natural paragraphs separating purpose, asset detection, and usage flow. Every sentence adds value, though some repetition (e.g., explaining widget interaction twice) could be trimmed. Front-loaded with core purpose.

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 complexity (multiple verification methods, widget integration, autonomous asset detection), the description is thorough. It covers when to use manually vs. via widget, how to obtain wallet_id, and the role of asset_symbol. An output schema exists (not shown here) which further reduces the need to describe return values.

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% with descriptions for all three parameters. The description adds significant extra meaning beyond schema: for wallet_id it warns not to show to user; for asset_symbol it explains it's an optional audit hint; for transaction_hash it is clear. This helps the agent use parameters correctly without ambiguity.

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 action: 'Submit a transaction hash for the dust/test transfer verification method.' It distinguishes from sibling tools like verify_wallet_signature by specifying the verification method (transfer vs. signature). The verb 'Submit' and resource 'transaction hash for verification' are specific.

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 explicit when-to-use instructions, including handling widget visibility ('if a Verify Wallet widget...tell the user to paste it into the widget's transaction-hash field') and fallback to get_wallet_summary. Also advises against a common negative response ('Do NOT respond with...') and clarifies when to omit asset_symbol.

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