mcp-server

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

Annotations only provide idempotentHint=true and destructiveHint=false. The description far exceeds that by disclosing client-side consent dismissal handling, no server-side blocking, chain-specific address behavior, zero-balance stealth-address caveats, exchange custody limitations, and Zcash shielded-address rejection. It also documents the widget rendering and instructs the agent not to read values aloud, which is critical behavioral guidance.

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 the length is justified by the large number of edge cases and user-facing behaviors it must cover. It is well structured with capitalized section labels (CANCELLED-CALL HANDLING, EVM CHAIN NOTE, ZERO-BALANCE NOTE, EXCHANGE CUSTODY, ZCASH) and the core purpose is front-loaded. A few repetitions could be trimmed, but the organization earns the length.

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, the description is exceptionally complete. It covers the success path, retry path, already-verified path, cancelled-call handling, chain support details, zero-balance nuance, exchange-custody alternatives, and Zcash restrictions. The output schema exists, so the description need not describe return values, and nothing essential to calling this tool correctly appears 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?

The schema has one well-described address parameter with 100% coverage, so the baseline is 3. The description adds extensive meaning beyond the schema: 0x addresses work across multiple EVM chains, bnb1 legacy addresses are unsupported, Zcash must be t-addresses, and the same 0x address serves BNB on BNB Smart Chain and Ethereum. This transforms the parameter from a generic string into a chain-aware input with concrete constraints.

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 opening sentence states a specific verb and resource: 'Submit a public wallet address for verification' and immediately lists what the tool does (detects blockchain, scans balances, returns verification options). It is clearly distinguishable from siblings like verify_wallet_signature and verify_wallet_transfer because it initiates the verification flow rather than completing it.

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 strong usage context: retry path for failed/unverified wallets, exchange-custody fallback to get_faq, and Zcash transparent-address prerequisites. It does not explicitly name the sibling verify tools as the next step after the widget flow, but the flow is implied well enough that an agent would know when to call 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?

Beyond the sparse annotations, the description discloses prerequisites, a 30-day download link, inline widget rendering, cancellation handling, and the ceiling constraint. It warns against using incorrect ceiling sources, adding important behavioral context not present in 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 clear sections for cancellation handling and ceiling. Every sentence serves a purpose, though some operational details could be condensed. It is appropriately sized for 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?

The description covers prerequisites, return value (download link, widget), error/retry handling, and the critical ceiling calculation. With an output schema present, it fully equips the agent to invoke the tool correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents both parameters (amount, currency) with descriptions, so baseline is 3. The description adds crucial constraint semantics for the amount parameter (must be ≤ pof_ceiling_usd from get_wallet_summary), which is not in the schema. This elevates the score to 4.

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 begins with a specific verb ('Generate') and resource ('Proof of Funds letter (PDF)'), clearly stating the action and output. It distinguishes itself from sibling tools like get_wallet_summary and verify_wallet_signature by focusing on document generation.

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 specifies preconditions (completed identity verification, at least one verified wallet) and explicitly recommends calling get_wallet_summary to check the ceiling. It also provides guidance on cancellation handling and when not to report success, giving clear expected usage.

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 the safety profile is known. The description adds valuable beyond-annotation context: that the response renders an inline progress widget and instructs the agent to keep its text to a short summary. It does not mention rate limits or authentication needs, but with zero parameters and clear read-only semantics, the behavioral transparency is strong. No contradiction 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 three sentences, each earning its place: first sentence states what the tool returns, second gives usage guidance and alternatives, third explains a key behavioral trait (the widget and agent response instructions). No fluff, front-loaded with the 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 zero parameters and a clear output schema (presence indicated), the description is complete. It states purpose, usage boundaries, and response behavior (widget rendering, agent response guidance). For a simple, zero-param, read-only tool with rich annotations, nothing 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 description coverage is 100% and there are no parameters, so the description has no additional parameter documentation burden. The description is clear that no input is needed, and it fully explains the information returned.

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 ('Returns') and resource ('high-level account overview'), and details exactly what is included: identity verification state, wallet count (not details), and Proof of Funds eligibility. It clearly distinguishes itself from sibling get_wallet_summary by specifying its scope is account-level, not wallet-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?

The description explicitly states when to use this tool ('is my account ready?' questions, resuming setup) and when NOT to use it (wallet summary, wallet list, wallet balances) with a direct alternative named: get_wallet_summary. It also explains the tool's unique value of providing the 'activation.next_action' for the user's state.

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. The description adds valuable context: returns up to 20 entries, fallback to category list on no match, and detailed behavior for recommended_next_action fields. No contradiction 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 front-loaded with purpose and usage, but the NEXT-ACTION METADATA section is lengthy and contains imperative instructions that could be more succinct. Still well-structured and clear, earning a 4.

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 two optional parameters, presence of output schema, and comprehensive annotations, the description covers purpose, fallback behavior, usage context, and post-use instructions. 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 description coverage is 100%, so baseline is 3. The description reiterates that the tool searches by keyword and/or category but adds no new semantic detail beyond what the schema already provides for each parameter.

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 starts with a clear verb+resource: 'Search RealOpen's frequently asked questions by keyword and/or category.' It uniquely identifies the tool's function and distinguishes it from sibling tools, none of which handle FAQ search.

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 guidance: 'Use this when a user asks a specific question about RealOpen's process...' and advises to prefer this over guessing. Also gives detailed instructions on handling next-action metadata, including when to offer next steps and when not to.

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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the response includes 'worked examples' and 'recommended_next_action fields,' and discloses the expected agent behavior (e.g., not leading with an offer, not repeating after decline). No contradiction 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 front-loaded with the core purpose, but the latter half on next-action metadata is verbose and repetitive. It could be more concise without losing essential guidance. Every sentence is earned, but the length reduces clarity.

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 and an output schema (indicated in context), the description sufficiently explains what the tool returns: pricing, fee breakdown, worked examples, and next-action metadata. Combined with annotations, the agent has all needed context to use this tool 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?

The input schema has zero parameters, so schema description coverage is 100% trivially. Per guidelines, 0 parameters merit a baseline of 4. The description adds no parameter information, which is acceptable 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 starts with 'Return RealOpen's current pricing and fee breakdown with worked examples,' which is a specific verb+resource pair. It clearly distinguishes from sibling tools like get_faq or get_how_it_works by focusing on fee-related queries.

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 'Use this whenever a user asks about RealOpen cost, fees, commissions, or total out-of-pocket' and emphasizes it supersedes model knowledge. The long next-action metadata section also provides detailed conditional guidance on when to offer a next step, which supplements the basic usage 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 readOnly/idempotent annotations, the description discloses that content is maintained by RealOpen and more current than model knowledge, and provides specific behavioral rules for handling recommended_next_action fields: never lead with offers, never paste metadata verbatim, and never repeat after a decline. This adds significant 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 front-loaded with purpose and usage, then transitions into a clearly labeled NEXT-ACTION METADATA section. While the metadata section is lengthy, it is structured and contains critical behavioral instructions. However, it could be slightly more concise without losing value.

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 the tool's purpose, content maintenance, perspective filtering, and the nuanced next-action behaviors. An output schema exists, so return values don't need detailing. For a content-retrieval tool with this complexity, the description is complete enough, though it could briefly mention what 'all' returns.

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 for the single 'perspective' parameter is 100%, with enums and descriptions already provided. The description's mention of perspective options (buyer, agent, escrow, overview) is essentially a restatement and adds minimal meaning beyond what the schema already documents. 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 it returns RealOpen's canonical explanation of how a crypto-to-real-estate transaction works, with a specific resource and scope. It uses a specific verb ('Return') and includes the perspective filter, but does not explicitly name sibling alternatives like get_faq, so it falls short of full differentiation.

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 context: 'Use this to answer any question about RealOpen's process, timing, or end-to-end flow' and instructs to 'always prefer it over guessing.' It also details when to offer the next action, but does not explicitly state when not to use the tool or mention alternatives, and there are no explicit exclusions.

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 useful context beyond this: the ref_id is automatically resolved from the authenticated user's record, so the model doesn't need to request it. This transparency helps the agent avoid unnecessary questions or assumptions.

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 sentences long, front-loaded with the primary purpose, followed by explicit usage guidance and a server-side note. Every sentence adds distinct value with 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?

For a simple one-optional-parameter tool with an output schema and strong annotations, the description adequately covers purpose, usage context, and an important behavioral nuance (server-side ref_id resolution). There are 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?

Schema description coverage is 100%, and the 'path' parameter is clearly described in the input schema with examples ('/how-it-works'). The description itself does not add further parameter-specific detail but implies the path refers to a realopen.com page. Baseline 3 is appropriate when the schema carries the semantic load.

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: 'Construct a tracked referral URL pointing at a realopen.com page.' This clearly distinguishes it from all sibling tools, none of which relate to referral links or marketing URL generation.

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?

Explicit usage guidance is provided: 'Use this whenever you produce marketing content, recommendations, or sign-up suggestions — append the returned URL so clicks are attributed.' It also tells the model not to ask for the ref_id because it's resolved server-side, which is valuable behavioral 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by noting that the response may include 'recommended_next_action fields', which reveals a behavioral trait beyond the annotations. No contradiction 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 padded with a large block of 'NEXT-ACTION METADATA' instructions that are meta-guidance for the agent, not a description of the tool itself. Only the first sentence pertains to the tool; the rest is extraneous and poorly structured for a tool definition. This violates conciseness and front-loading principles.

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 has no parameters, an output schema exists, and annotations are present, the description should be complete. The first sentence explains what the tool returns and when to use it. However, the extra meta-instructions dilute focus but do not omit essential information. It is adequate for the agent to understand the tool's purpose.

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 (input schema is empty), and schema description coverage is 100%. The description does not need to explain parameters. It briefly mentions output fields, which is adequate but not required. Baseline for zero-parameter tools is 4.

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 current geographic coverage, supported property types, and international availability' with specific verb and resource. It also gives concrete usage examples (e.g., 'whether RealOpen operates in a particular state, country, or property type'), which distinguishes it from siblings like get_faq or get_how_it_works.

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 whenever a user asks whether RealOpen operates in a particular state, country, or property type', providing clear when-to-use guidance. It does not mention when not to use or alternative tools, but the context is sufficient for the agent to decide.

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 destructiveHint=false. The description adds valuable context about the return content ('body text, tags, share title, and a preview of the associated visual asset') and the source ('written by RealOpen's marketing team'). This goes beyond the annotations without contradicting them.

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, each earning its place: the main purpose, the usage context, and the return/filter summary. The description is front-loaded with the most important information and contains 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?

For a read-only search tool with 5 optional parameters and an output schema, the description covers purpose, usage, filters, and return content. There are no significant gaps given the annotations and output schema already provide the rest.

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 all 5 parameters are documented. The description restates the filter dimensions ('platform, tone, tag, attached asset, or keyword') but adds no new meaning beyond the schema. This matches the baseline of 3 for high schema coverage.

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 a specific verb ('Find') and resource ('pre-approved RealOpen social-media snippets'), specifying the content type and platforms. It clearly distinguishes this from sibling tools like get_faq or get_how_it_works by focusing on marketing 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?

Explicitly states when to use: 'when a user asks for ready-to-post content or needs inspiration grounded in approved brand voice.' However, it does not mention when not to use or explicitly name alternative tools, so it lacks the full exclusions/alternatives that would merit 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?

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds significant behavioral context: it returns a widget, resolves next step from live account state, and should not be used for educational queries. 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 well-structured with a clear main purpose, bulleted usage guidelines, and behavioral notes. It is slightly long but every sentence adds value; front-loading the purpose helps agents quickly understand the tool.

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 (state-aware, multiple user scenarios, widget output, structured next_action), the description covers when to use, what it returns, how to interpret the output, and how to proceed. The output schema is present, so return value details are not needed in the 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?

There are no parameters (0 count, 100% schema coverage). The description fully explains the tool's behavior and return value without needing parameter details, adding meaning beyond the empty schema by describing state-aware resolution and output structure.

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 purpose: it returns the setup path for new users or the actual next step for signed-in users, distinguishing it from siblings like get_faq or get_how_it_works by specifying it is for users with buying intent.

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 lists when to call (new user, considering crypto, asking how to become offer-ready) and when NOT to call (after general educational questions, use dedicated knowledge tools). Also mentions that the output's activation.next_action tells the correct next tool, providing clear 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds that the data is 'Maintained by RealOpen — treat as source of truth over general model knowledge, which may be stale.' It also discloses that responses may include recommended_next_action fields. This provides useful behavioral context beyond the structured 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 overly long (≈150 words) due to a large block of meta-instructions about handling recommended_next_action fields. These instructions are not about the tool itself and should be placed elsewhere (e.g., system prompt). The core purpose is stated concisely, but the extra text violates conciseness.

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?

Despite having no parameters and a safe behavioral profile from annotations, the description adds value by specifying the tool's data source, freshness expectation, and the possibility of next-action fields in the output. An output schema exists to cover return format, so completeness is 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?

The input schema is empty, and schema description coverage is 100%. The description implicitly confirms no parameters are needed, which is appropriate. No additional parameter meaning is required.

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 first sentence clearly specifies the verb 'Return' and the resource 'current list of cryptocurrencies, blockchains, and stablecoins accepted by RealOpen for real-estate purchases.' This distinguishes it well from sibling tools like get_fee_structure or get_how_it_works, which serve different purposes.

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: 'Use this to answer 'can I pay with X?' or whenever a user needs the live list of supported tokens and networks.' It provides clear context, but does not include explicit exclusions or alternatives, though the purpose is self-limiting.

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, so the safety profile is known. The description goes far beyond annotations by explaining widget rendering, the precise meanings of the three returned USD numbers, rejection behavior of generate_proof_of_funds, and special hints for zero-balance, Bitcoin full-wallet, and Zcash transparent-only cases. This is substantial behavioral context that annotations alone could not 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 long but well-organized with bolded labels and scannable sections. It front-loads the trigger and core purpose before diving into cautionary notes. A few warnings repeat the same point, especially around never using total_usd or total_verified_usd as the POF ceiling, but the redundancy is likely intentional for a high-stakes numerical distinction.

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 tool with no parameters and an output schema, the description still provides complete operational context: what counts as a valid POF ceiling, how to handle the widget, what to do with zero_balance_hint, full_wallet_hint, and transparent_only_hint, and how to route the next step to generate_proof_of_funds. An agent has everything needed to invoke this tool correctly and avoid common mistakes.

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 zero parameters, so the input schema carries no burden and the baseline is 4. The description adds useful meaning about the result fields and their distinctions (pof_ceiling_usd, total_verified_usd, total_usd), which is enough for correct use. Nothing more is needed for 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 names a specific verb and resource family: 'Call this whenever the user asks for a wallet summary, wallet list, their wallets, wallet balances, verified holdings, or Proof of Funds ceiling.' It states exactly what is returned: all wallets, balances, verification status, and POF ceiling. It is clearly differentiated from siblings like generate_proof_of_funds and refresh_wallet_balance by tying this tool to summary/list/balance 'asks'.

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 guidance is explicit and actionable: it lists trigger phrases, instructs the agent to let the widget handle presentation, and tells it to pass pof_ceiling_usd to generate_proof_of_funds when generating a POF. It also gives strong 'never' rules, such as never using total_usd or total_verified_usd as the POF ceiling, and never implying an unverified zero-balance wallet is empty. This gives clear when-to-use and when-not-to-use behavior.

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 only signal readOnly=false, idempotentHint=true, destructiveHint=false; the description adds substantial behavioral context: safety rules about private keys, the fact that public keys reveal addresses/balances, pending verification activation flow, unlink side effects, and binding-failure error interpretation. This goes well beyond the annotations and is critical for safe use.

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-organized with clear topic areas (purpose, when to use, wallet-specific instructions, safety, success handling). Each section earns its place given the security-sensitive and multi-step nature of the tool, though the wallet-specific 'where to find it' listing could be trimmed without losing core invocation guidance.

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, timing, prerequisites, verification states, safety, user guidance, success output highlights, error handling, and unlink behavior. With an output schema present, return values do not need full explanation, and the description still mentions the key success fields. Nothing important for correct invocation 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?

Although schema coverage is 100%, the description adds meaningful parameter guidance: xpub format/prefixes/length and its omission when unlink is true, wallet_id as an internal UUID from get_wallet_summary that must not be shown to the user, and the semantic of unlink. This is additional value beyond the schema, not repetition.

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 (link or remove), the resource (extended PUBLIC key of a verified Bitcoin/Zcash wallet), and the purpose (every address counts toward balance/Proof of Funds). It explicitly scopes to Bitcoin and Zcash transparent addresses only and distinguishes itself from related wallet operations by referencing full_wallet_hint and verification workflows.

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 when-to-use triggers: verified BTC wallet shows less than expected, get_wallet_summary/refresh_wallet_balance returns full_wallet_hint, or user mentions a hardware/HD wallet. It also recommends offering it right after add_wallet and names the unlink behavior, providing clear decision context versus sibling tools.

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 annotations already declaring idempotentHint=true and destructiveHint=false, the description adds only minimal behavioral context by specifying the session scope ('RealOpen MCP session') and typical use cases. It does not go into further side effects or post-conditions, but the annotation coverage reduces the need for extensive disclosure.

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 short sentences, front-loaded with the action, and contains no redundant information. Every phrase 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 logout tool with an output schema and annotations, the description is complete. It states the action, the target session, and when to use it, leaving no critical 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 tool has zero parameters, so the baseline is 4. The description appropriately does not discuss parameters since none exist, and the schema already fully covers this (100% coverage vacuously).

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 function: 'Sign out of your RealOpen MCP session.' It uses a specific verb ('Sign out') and identifies the resource (RealOpen MCP session), fully distinguishing it from all sibling 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?

Explicit usage guidance is provided: 'Use this when the user wants to switch accounts or disconnect.' This gives clear conditions for when to invoke the tool and implicitly when not to.

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 goes far beyond the annotations: it discloses that empty or no-USD fetches preserve the existing balance and return status=no_change, explains linked_addresses as cryptographically proven owned, warns against assuming zero-balance wallets are empty, and explains consolidation_hint behavior. This is consistent with annotations; readOnlyHint=false aligns with 'update the stored record.'

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 core purpose and trigger are front-loaded, and the long caveats are clearly labeled as notes. However, the zero-balance warning is repeated across the ZERO-BALANCE, BITCOIN, and ZCASH notes, and the description appears to end mid-sentence at the Zcash note, so it is somewhat longer and less tidy than ideal.

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 the trigger, mutation semantics, preservation behavior, linked addresses, presentation requirements, and multiple zero-balance edge cases. The output schema handles return-shape details. The main gap is that the text appears truncated at the Zcash note, leaving that final instruction incomplete.

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 already fully documents wallet_id, including that it is an internal UUID from get_wallet_summary or add_wallet and should not be shown to the user. With 100% schema description coverage, the description adds no additional parameter-level semantics, 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 a specific verb and resource: 'Re-fetch on-chain asset balances for an existing wallet and update the stored record.' It clearly distinguishes this tool from siblings like get_wallet_summary or refresh_wallet_verification by centering on balance refresh and update semantics.

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 an explicit trigger: 'Use when the user says their balance looks stale, wrong, or zero after a recent on-chain change.' It also provides conditional guidance for empty results, zero-balance hints, BTC consolidation hints, and Zcash re-fetch/linking suggestions, which tells an agent how to behave in key edge cases.

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?

Given annotations only provide readOnlyHint=false, openWorldHint=false, idempotentHint=false, and destructiveHint=false, the description adds substantial behavioral context. It explains the widget renders inline, user interacts via clicking rather than reading values aloud, that the widget internally calls verify_wallet_signature/verify_wallet_transfer, that those silent calls may not produce visible follow-up, and that prior output becomes stale after widget use. This goes far beyond the annotations and is essential for correct agent 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?

The description is long but every sentence carries necessary operational detail: purpose, return shape, widget behavior, post-verify re-check procedure, and rejection of stale output. It is front-loaded with the main purpose and progressively adds context, with no filler or 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?

Despite having an output schema, the description still explains the response shape and the widget's behavior, which is critical for interpreting results. It also covers edge cases like silent internal calls and stale output, making the description fully complete for the tool's complexity and the scenario of user interaction.

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 description does not mention wallet_id at all; all parameter semantics (e.g., 'Internal wallet UUID', 'Do NOT show this ID') are provided in the input schema. Since schema description coverage is 100%, the baseline of 3 applies, but the description itself adds no incremental parameter meaning.

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 a specific verb+resource: 'Regenerate verification challenges for an existing unverified wallet.' It clearly distinguishes this from related sibling tools like add_wallet, verify_wallet_signature, and get_wallet_summary by focusing on regeneration of challenges after failed attempts or fresh need.

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?

Explicit when-to-use guidance is given: 'Use this when a previous verification attempt failed, or when the user needs a fresh message to sign or a new transfer challenge.' It also instructs when NOT to rely on prior output and directs to call get_wallet_summary after widget use, effectively naming an alternative for re-checking verification status.

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?

Goes far beyond the destructiveHint annotation by detailing exactly what gets deleted (wallet record, verification status, balance history) and the downstream effect on Proof of Funds ceiling. This is rich behavioral context that annotations alone do not 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 compact yet dense with essential information. Each sentence conveys critical operational guidance—confirmation, address reference, UUID privacy, and ceiling impact—without filler or 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?

Given the destructive nature and complexity, the description covers all necessary operational details: what is deleted, how to confirm with the user, communication constraints, and side effects. Combined with the existing output schema and annotations, the context is fully specified.

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 already provides full coverage (100%) with a detailed description of wallet_id, including the instruction not to show it to the user. The tool description repeats this guidance but does not add new parameter semantics beyond reinforcing existing schema content, so 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 function: 'Permanently remove a wallet from the authenticated user's account.' It specifies the resource (wallet) and distinguishes it from siblings like add_wallet, making the purpose unmistakable.

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 strong usage context: requires explicit user confirmation, instructs how to identify the wallet (by address, not UUID), and notes the ceiling impact for verified wallets. However, it does not explicitly mention when NOT to use the tool or alternative tools, so it falls 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.

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

Annotations already declare readOnlyHint true and idempotentHint true, so the description doesn't need to restate safety. It adds valuable behavioral context: result cap of 20 assets, included fields (URLs, captions, tags), and inline thumbnail previews for the first five. This goes beyond the structured 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, each earning its place: the first states the core function and resource, the second provides usage context and output details. No redundancy, no filler. Well 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?

For a search tool with four optional parameters and an output schema, the description covers the essential points: asset library, filter dimensions, result limit, and preview behavior. It doesn't explain sorting or default behavior, but those are not necessary given the output schema exists.

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% for all four parameters, each with a clear description. The tool description merely summarizes that you can filter by keyword, category, tags, or file type, 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 opens with a specific verb and resource: 'Search RealOpen's library of approved affiliate marketing assets.' It enumerates asset types (flyers, social graphics, email banners, etc.), making the tool's scope unmistakable. This clearly differentiates it from sibling tools, which revolve around wallets, proofs, and FAQs.

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 an explicit use case: 'Use this when a user asks for existing RealOpen marketing material they can download or share.' It does not mention alternatives or when-not-to-use, but given the sibling toolset, no direct alternative exists, making this guidance sufficient.

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 valuable behavioral context beyond the annotations: it explains that a new session is created for incomplete/denied/expired previous sessions and that it returns a user-facing URL. This complements the annotation flags (e.g., readOnlyHint=false) without contradicting them.

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 purpose, and each sentence provides essential operational details (session handling and URL return). There is no unnecessary wording.

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 tool with only two optional parameters and an output schema, the description covers the core behavior, session-restart logic, and the return value (URL). It is sufficiently complete for an agent to understand when and how to invoke 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?

The input schema already contains full descriptions for both parameters (force_new and id_number_required) with 100% coverage. The description does not add meaning beyond the schema, so a 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 starts or restarts identity verification (KYC), using a specific verb and resource. It also distinguishes itself from sibling tools by focusing on identity verification sessions and the behavior regarding previous sessions.

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 clear context on when to use the tool: when starting or restarting identity verification, including after incomplete, denied, or expired sessions. However, it does not explicitly mention alternatives or exclusion scenarios, but the provided context is sufficient for an agent to select it appropriately.

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 no safety hints (all false), so the description carries the full transparency burden. It discloses a non-obvious behavioral trait: the widget automatically invokes this tool with the correct wallet_id, meaning the agent should not call it when the widget is visible. It also warns against a specific failure response and directs the agent to get_wallet_summary for lookup, providing rich 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?

The description is long and includes a capitalized conditional section, but every sentence serves a purpose—there's no fluff. The structure is logical (purpose, user instruction, widget vs. direct-call decision tree, and a corrective warning). While longer than ideal, it remains well-organized and front-loaded with the core action.

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 interactive complexity (widget visibility, wallet_id lookup, user signature collection), the description covers all necessary scenarios and even anticipates a common mistake. With an output schema present, return-value details need not be explained. The guidance is complete enough for an agent to select and invoke the tool correctly in any situation.

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. The description adds meaningful extra context: it reminds the agent to ask the user for the 'full signature hash' and clarifies that wallet_id must never be shown or requested from the user, reinforcing the schema's caution with concrete workflow steps. This pushes it above baseline.

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 'Submit a signed message to verify wallet ownership,' which is a specific verb+resource combination that clearly distinguishes this tool from siblings like verify_wallet_transfer. The purpose is unambiguous and directly tied to wallet ownership verification.

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 when-to-use guidance: use the widget if visible, otherwise call get_wallet_summary first to find the wallet_id. It also provides a clear exclusion ('the widget calls this tool itself, no work needed from you') and names the alternative lookup path, covering when/not 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?

Annotations only indicate this is not read-only and not idempotent, so the description must disclose behavior itself. It explains the verifier's internal asset auto-matching, accepts block-explorer URLs and extracts the hash, rejects exchange reference IDs with a specific error name, and instructs relaying assistant_guidance. It also clarifies that wallet_id is not something to ask the user for, which is a crucial behavioral rule beyond any structured field.

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?

Although lengthy, the description is organized into clear blocks: hash format, asset detection, widget-related flow, and fallback path. Every sentence carries an operational constraint or user-facing behavior. The length is justified by the complexity of the verification workflow and the number of failure modes it preempts.

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 is complete for real use: it specifies prerequisites, widget-state handling, a fallback with get_wallet_summary, and the invalid-transaction-hash error path. Since an output schema exists, the description does not need to cover return values. Nothing needed to call the tool correctly is left unattended.

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% for the three parameters, which earns the baseline 3, but the description adds substantial semantic value. It documents per-chain hash formats, the handling of URLs, the rejection cases for exchange IDs, and the harmless/reflection-only nature of asset_symbol. This materially helps an agent decide what to put into transaction_hash and whether to omit asset_symbol.

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 a specific verb and object: 'Submit a transaction hash for the dust/test transfer verification method.' This clearly targets the wallet-transfer verification workflow and ties it to a deposit address provided by add_wallet. The use of 'transaction hash' and 'transfer verification' plausibly differentiates it from the sibling verify_wallet_signature, even without an explicit 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?

It gives concrete when-to-use rules: only after the user has sent a valid transfer to a deposit address, and while or when a Verify Wallet widget is, or isn't, visible. It also prescribes a concrete fallback: call get_wallet_summary first to resolve wallet_id, and it explicitly warns against a common wrong approach. This is far more actionable than most tool descriptions.

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