mcp-server

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

Annotations only say readOnlyHint=false, openWorldHint=false, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral context: it detects the blockchain, scans balances, returns verification options, renders an inline widget, handles cancelled consent prompts, and warns that the widget's internal verify calls may not produce a visible follow-up. It also discloses chain-specific behaviors (EVM chain-agnostic signature verification, Zcash transparent-only, Dogecoin multisig test-transfer, ETC not a settlement asset). This is rich behavioral disclosure that goes far beyond the annotations and does not contradict 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 extremely long and covers many edge cases (Zcash, Dogecoin, ETC, exchange custody, zero-balance, cancelled-call handling, post-verify re-check). While every section adds real guidance, the sheer length makes it harder to parse, and some details (e.g., the full ETC settlement explanation) could be trimmed or moved to a linked FAQ. It is front-loaded with the core purpose and the most important retry/verification flow, but the density of special cases hurts scannability.

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 — one parameter, an output schema, and many chain-specific behaviors — the description is remarkably complete. It covers the main flow, the retry path, the already-verified case, the widget behavior, the stale-output trap, exchange custody, zero-balance hints, Zcash transparent-only, Dogecoin multisig, and ETC settlement status. An agent has everything it needs to invoke the tool correctly and to handle follow-up user questions without hallucinating.

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 parameter, address, with 100% description coverage ('The public wallet address to add'). The description adds meaning by specifying accepted address types (Bitcoin, Ethereum, Solana, stablecoin wallets, other supported chains), noting that 0x... addresses are verified across multiple EVM chains, and clarifying that legacy Beacon Chain bnb1... addresses are not supported. It also says to identify the wallet by address, never by wallet_id. Since the schema already covers the parameter and the description enriches it with format and chain details, a 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 opens with a specific verb and resource: 'Submit a public crypto wallet address... so RealOpen can verify ownership and count its holdings toward a crypto Proof of Funds letter.' It clearly distinguishes the tool's role from siblings like verify_wallet_signature, verify_wallet_transfer, and get_wallet_summary by explaining that this tool initiates verification and returns verification options, while the widget internally calls the verify tools. It also names the retry path and the already-verified case, so an agent can tell exactly what this tool is for.

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 and when-not-to-use guidance: use it to add a wallet, retry it for FAILED/unverified wallets, and do NOT force it for exchange-held assets (search get_faq for 'exchange' instead). It also instructs the agent to call get_wallet_summary after the widget is used, and to ask Zcash users about transparent vs shielded addresses before starting. This is far beyond a minimal usage note and directly routes the agent to 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 the annotations, the description discloses several important behaviors: the client-side consent prompt cancellation, the 30-day download link validity, the inline widget presentation, and the rule that success must not be reported unless a download_url was actually returned. It clarifies that the tool creates a letter only, which aligns with readOnlyHint=false 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?

The description is long but every sentence earns its place: context, prerequisites, download-link lifespan, widget handling, cancellation handling, and ceiling constraints are all operationally relevant. The main purpose is front-loaded, and advanced caveats are grouped into labeled sections (CANCELLED-CALL HANDLING, CEILING), making it easy to parse.

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?

This is a side-effectful, non-idempotent tool with external validation and UI feedback, and the description covers all of it: prerequisites, return-link validity, widget behavior, error handling for canceled calls, and the ceiling rule. With an output schema present, return-values need no prose, and the failure-handling guidance addresses the most likely agent mistake.

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 crucial semantic value for amount by introducing the pof_ceiling_usd constraint from get_wallet_summary and warning against using total_verified_usd or wallet sums as ceilings. Currency, however, receives no additional nuance beyond the schema's enum/default.

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 ('Generate'), names the artifact ('crypto Proof of Funds letter (PDF)'), and the subject ('the authenticated user'). It also distinguishes the tool from sibling getters by explaining the document's real-estate context, so an agent can immediately tell this is a document-generation call, not a data-retrieval one.

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 the use case (attach to a cash offer on real estate), prerequisites (completed identity verification and at least one verified wallet), and a when-not boundary ('creates a letter only — it does not move, convert, or reserve any funds'). It also instructs the agent to call get_wallet_summary first when unsure of the ceiling, which is explicit cross-tool 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 already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond that: the response includes activation.next_action as the single correct next step, and it renders an inline progress widget with instructions to keep agent text short. This helps the agent know what to expect and how to respond.

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 dense but every sentence earns its place: what the tool returns, what it does not return, the sibling to use instead, the primary use cases, the key response field, and the widget presentation guidance. Key information is front-loaded in the first sentence.

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, read-only tool with an output schema, the description is complete. It covers the return contents, the critical next-action field, presentation behavior, and explicit routing away from get_wallet_summary. Nothing needed to call or interpret the tool correctly 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?

The tool has zero parameters, so there is no parameter semantics to document. Per calibration, a zero-parameter tool earns a baseline of 4; the description correctly avoids inventing parameter details.

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') with a specific resource ('high-level account overview') and names the exact components: identity verification state, wallet count, and Proof of Funds eligibility. It also explicitly distinguishes itself from get_wallet_summary, so an agent can select it correctly without ambiguity.

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 ('answering "is my account ready?"-style questions' and 'resuming setup') and explicit when-not-to-use guidance with the named alternative ('DO NOT call this when the user asks for a wallet summary... use get_wallet_summary'). This fully covers selection 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the 20-entry result cap, the no-match fallback that returns available categories, and a detailed recommended_next_action protocol governing when and how to offer next steps, including prohibitions on leading with the offer and repeating after a decline. This is rich behavioral context that annotations alone would not provide, with no 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?

The description is front-loaded with purpose, followed by usage, fallback, and metadata-handling sections — each serving a distinct function. It is on the verbose side, especially the NEXT-ACTION METADATA block, which could be tightened, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description correctly focuses on behavior: what inputs mean, what outputs look like (up to 20 entries, category fallback), and the required post-call protocol. An agent has everything needed to invoke the tool correctly and handle its results.

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 earns a 4 by clarifying that query and category can be used together or separately ('by keyword and/or category') and by illustrating that query accepts natural-language questions via its many examples.

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+scope: 'Search RealOpen's frequently asked questions about buying real estate with crypto, by keyword and/or category.' Concrete example topics (seller receiving dollars, crypto-backed cash offers, proof of funds, taxes, closing) make the domain unmistakable and implicitly distinguish it from siblings like get_fee_structure and get_supported_crypto.

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 provided: 'Use this when a user asks a specific question about the process' followed by concrete examples, plus the directive 'Prefer this over guessing from general knowledge.' However, there is no explicit when-not-to-use or routing to alternative siblings for overlapping topics (e.g., fees vs. get_fee_structure).

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 the tool reflects the live fee schedule and supersedes any estimates from model knowledge, setting accurate freshness expectations. It also documents the nuanced response behavior around recommended_next_action fields: keep the factual answer primary, never paste the metadata verbatim, and never repeat the offer after a decline.

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 is front-loaded in one clear sentence, and the next-action guidance is clearly separated under a label rather than mixed into the main purpose. The description is long, but the additional instructions are operational guardrails that earn their place; it only loses a point for including response-policy detail that goes beyond simple tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and an output schema already present, the description provides everything an agent needs: what the fee data covers, that it is live and authoritative, when to use the tool, and how to handle subsequent next-action offers. 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?

The tool has zero parameters and 100% schema coverage, so there is no parameter ambiguity for the description to resolve. This matches the baseline expectation for a no-parameter tool; no additional parameter explanation is 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?

The description opens with a specific verb ('Return') and identifies the exact resource: RealOpen's current pricing and fee breakdown for buying real estate with crypto, including worked examples. This clearly distinguishes it from sibling tools like get_supported_crypto or get_how_it_works, and the annotation title 'Fees for Buying With Crypto' reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this whenever a user asks what it costs to buy a house with Bitcoin or other crypto through RealOpen,' covering fees, commissions, and total out-of-pocket costs. It also provides conditional guidance about when not to make a next-step offer (professionals, idle research, after a decline) and names get_started as the tool to call if the user accepts.

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 substantial behavioral context beyond the annotations: it reveals that real crypto-to-fiat conversion and closing happen outside the chat, that the tool only provides explanations, and that this content is maintained by RealOpen and should be preferred over model guessing. It also discloses the special next-action metadata behavior and how to handle recommended_next_action fields, which is not visible in any annotation or schema.

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 description is front-loaded with a clear, single-sentence purpose, followed by usage examples and a filter list. The next-action metadata paragraph is lengthy but contains necessary behavioral instructions that earn their place; it is structured and not redundant. It is somewhat longer than strictly necessary but remains focused.

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 is complete for this tool's complexity: it covers the tool's scope, the input perspective semantics, the boundary of what the tool does not do, and the special next-action handling. The presence of an output schema means return-value details do not need to be repeated, and the description leaves no obvious gap an agent would need before invoking the 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?

Schema coverage is 100% and the schema already documents the perspective enum with descriptions. The description adds interpretive meaning by mapping perspectives to concrete contexts: 'buyer step-by-step', 'agent/seller-side', 'title/escrow company settlement', and 'high-level overview', which helps the agent select the right value without opening the schema. It does not, however, explicitly mention the 'all' default.

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: it explains RealOpen's canonical end-to-end flow for buying real estate with crypto, from verified crypto holdings to a cash offer to closing. It clearly distinguishes this tool's scope from a generic how-it-works or FAQ by noting that it is the canonical process reference and 'only explains the process'.

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 the agent when to use it: for questions like 'how can I buy a house with Bitcoin?' and any question about RealOpen's process, timing, or end-to-end flow. It also implies a when-not by stating the tool only explains the process and that actual conversion, funding, and closing happen outside the chat, but it does not name any alternative sibling tools such as get_faq or get_started.

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 establish readOnly/idempotent/non-destructive behavior. The description goes well beyond this by disclosing that the response may include recommended_next_action fields, that these indicate possible purchase intent, and how the agent should handle them—including when not to offer the next step. This is meaningful behavioral context not present in 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 first sentence is tightly scoped and front-loaded with the core purpose. The NEXT-ACTION METADATA section is longer and reads more like an operational policy than a pure tool description, but every sentence serves a real purpose. It is slightly verbose relative to the tool's simple parameter surface, though not redundant.

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, annotated read-only tool with an output schema, the description covers everything needed: what data is returned, when to invoke the tool, and how to handle the metadata in the response. No critical operational gap remains.

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, and schema description coverage is 100%. There is no parameter-level meaning for the description to add, so the baseline of 4 applies. The description focuses appropriately on the returned information instead of inventing non-existent 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 uses a specific verb ('Return') and a concrete resource: where a buyer can use crypto to buy real estate through RealOpen. It names the exact dimensions of the answer (geographic coverage, supported property types, international availability), which clearly differentiates it from a sibling like get_supported_crypto and leaves no ambiguity about the tool's scope.

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 trigger conditions: 'Use this whenever a user asks whether they can buy a house with crypto in a particular state or country, or whether RealOpen supports a property type.' It does not mention when not to use it or name an alternative tool, so it falls short of the 5-level, but the context is clear and actionable.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds meaningful behavioral context beyond those: it states that no funds move, conversion/funding/closing happen outside the chat, the response renders an inline widget, and the structured activation.next_action tells the agent the correct next tool. This fully discloses what the tool does and does not do.

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 dense, but every sentence carries routing, behavioral, or presentation guidance that would otherwise be missing. It is front-loaded with the core purpose. It could be tightened or bulleted, but the length is justified by the tool's broad trigger vocabulary and the need to prevent misuse.

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 and strong sibling context, the description is complete: it covers target users, intent thresholds, exclusions, non-mutating behavior, widget presentation, and the role of activation.next_action. Nothing an agent needs to decide when to call it and what to expect is left unexplained.

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 and 100% schema coverage, so the baseline is 4. The description cannot add parameter-level detail because none exist, but it does add operational semantics by explaining that behavior is driven by live account state and that activation.next_action encodes the next step.

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 concrete verb-and-resource statement: it is the front door to buying real estate with crypto, returning the setup path and resolving the actual next step from live account state. It explicitly contrasts itself with knowledge tools, distinguishes new-user versus signed-in behavior, and makes its scope ('preparation only') unambiguous.

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 explicit trigger conditions ('call this when: the user is new ...') and an explicit exclusion with the alternative ('Do NOT call it after every general educational question ... answer with the dedicated knowledge tools'). This is model-tier routing guidance, including when to defer to sibling knowledge 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing that results are live/current ('treat as source of truth') and by explaining the NEXT-ACTION METADATA handling behavior. 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 purpose is front-loaded in the first sentence, which is good. However, the NEXT-ACTION METADATA block consumes roughly half the description and is verbose operational policy rather than tight tool semantics. It earns some place given it dictates agent behavior, but could be trimmed.

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 0-parameter tool with an output schema (documenting return values) and annotations (covering safety), the description covers purpose, usage triggers, and post-response behavior. Nothing an agent needs to call it correctly 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?

Tool has zero parameters, so baseline is 4 per rubric. There is nothing to document, and the description correctly focuses on the returned data rather than inputs.

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

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

States a specific verb and resource ('Return the current list of cryptocurrencies, blockchains, and stablecoins') tied to the RealOpen buying context, and gives concrete example queries. This clearly distinguishes it from sibling tools like get_faq or get_fee_structure, which answer different questions.

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 specifies when to invoke it ('Use this to answer...') and positions it as the authoritative source over stale model knowledge. It doesn't name sibling alternatives or state when not to use it, but for a 0-parameter lookup tool the context is clear enough.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive, but the description adds substantial behavioral nuance: the haircut math behind pof_ceiling_usd, exclusion of unverified wallets, ETC counting toward the ceiling but not settlement, zero-balance and full-wallet hints, Zcash transparent-only verification, and staking liquidity constraints. This goes far beyond what the annotations express.

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 section earns its place: the three critical POF numbers are isolated and labelled, and topic areas (presentation, linked addresses, zero-balance, Bitcoin, Zcash, staking) are clearly flagged. It front-loads the core invocation condition and then layers caveats in a way that prevents costly agent mistakes.

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 tool with no parameters and an output schema, the description is exceptionally complete: it covers all returned data categories, widget behavior, user-facing vs internal identifiers, asset caveats, staking states, and hints the response may carry. An agent can invoke correctly and interpret the results without needing additional 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?

The tool has zero parameters, so the 0-parameter baseline of 4 applies; there is no schema information for the description to supplement. The description also clarifies that wallet_id is an internal UUID to be used only as a parameter for other tools, which is useful cross-tool semantic context even though it does not apply to this tool's empty input 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 opens with explicit trigger phrases ('wallet summary, wallet list, their wallets, wallet balances, verified holdings, or Proof of Funds ceiling') and states the resource: authenticated user's wallets plus balances, verification status, and POF ceiling. It clearly differentiates this from the POF generator by emphasizing the ceiling is the only valid maximum for a Proof of Funds letter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Call this whenever the user asks...' and gives concrete behavioral guidance: summarize counts in text, let the widget handle presentation, never offer ETC as settlement, suggest POF amounts at or below pof_ceiling_usd, and offer link_wallet_xpub when balances look low. This tells the agent not only when to use the tool but how to use its results responsibly.

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 readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which are minimal. The description goes far beyond by detailing verification statuses (linked vs pending_verification), the automatic activation upon wallet verification, the safety rule never to accept private keys, the success output (total_btc, total_usd, funded_address_count), and the binding-failure error meaning. It also explains multisig behavior. This fully discloses the tool's 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 extremely long but well-structured: it front-loads the core purpose and conditions, then provides verification details, wallet-specific instructions, safety warnings, success handling, and multisig notes. Every sentence carries operational information, but the length could be trimmed without losing critical guidance. It is appropriately sized for the complexity but not concise; it earns 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 the tool's complexity (multiple currencies, verification states, multisig, safety), the description is complete. It explains the output format (total_btc, total_usd, funded_address_count) and common error handling (binding failure). It also covers the 'where to find' for common wallets, which is essential for an agent. Nothing an agent needs to invoke correctly 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 the schema already describes all three parameters at 100% coverage, the description adds crucial semantics: it clarifies the xpub prefixes (xpub, ypub, zpub, dgub), specifies the multisig alternative (output descriptor or Unchained config), explains when to omit xpub (when unlink=true), and explicitly warns never to pass private keys. It also clarifies wallet_id is an internal UUID not to be shown. This adds significant value 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 opens with a specific scoping (BITCOIN, ZCASH transparent, DOGECOIN ONLY) and a precise verb+resource: 'Link (or remove) the extended PUBLIC key' so that all addresses count toward balance and Proof of Funds. It clearly distinguishes the tool from siblings like add_wallet and refresh_wallet_balance by stating exactly when it applies (hardware/HD wallets, full_wallet_hint).

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 it: when a verified wallet shows less than expected, when get_wallet_summary or refresh_wallet_balance returns full_wallet_hint, or when the user mentions hardware/HD wallets. It also instructs to offer it right after add_wallet for relevant users, and explains when to use unlink: true. This is explicit and action-guiding.

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?

Annotations indicate this is a write operation (readOnlyHint=false) and idempotent, which the description does not contradict (it states existing balance is preserved on no_change). The description goes beyond annotations by detailing edge cases: empty results preserve state, privacy features may hide funds, Bitcoin full-wallet behavior, Zcash transparent-only counting, and staking value non-transferability. It does not explicitly say it updates a record, but 'update the stored record' is present, so this is clear.

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 thorough, but it front-loads the core purpose and trigger. The many notes (zero-balance, bitcoin, zcash, staking) are necessary given the tool's complexity, but they make it dense and could be more structured with bullet points. It is arguably over-specified for an agent to parse, though every note serves a 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 tool's complexity (multiple chains, hints, and edge cases), the description covers every relevant scenario: returning no_change, linked_addresses, zero_balance_hint, xpub_linked/full_wallet_hint, transparent_only_hint, and staking hints. It also covers agent presentation guidance (table, highlights) and user interaction (relay hints). The output schema exists, so return value details are not required. This is complete for an 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?

The schema already fully documents wallet_id (coverage=100%), including that it is an internal UUID and a lookup instruction. The description adds no extra syntax or semantics for the parameter, relying on the schema. This is a baseline score of 3 since the schema does the heavy lifting.

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 the tool's purpose precisely: 'Re-fetch on-chain asset balances for an existing wallet and update the stored record' – a clear verb, resource, and effect. It explicitly ties the fetched balances to the 'Proof of Funds ceiling', establishing domain context. It also distinguishes from siblings (e.g., refresh_wallet_verification, get_wallet_summary) by focusing on balance refresh rather than verification or reading.

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 trigger: 'Use when the user says their balance looks stale, wrong, or zero after a recent on-chain change.' It also states safeguards (no_change preserves existing balance) and instructs to relay various hints (zero_balance_hint, full_wallet_hint, staking_hint) and suggest follow-ups like link_wallet_xpub. This is a complete 'when and how' guide.

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?

Beyond the destructiveHint annotation, the description explicitly states what will be deleted: 'the wallet record, its verification status, and associated balance history.' It also discloses the side effect on Proof of Funds ceiling. This gives the agent full awareness of consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet thorough, using clear warnings and structured sentences. It covers all necessary points without redundancy. Every sentence adds value, and the emphasis on confirmation is appropriately placed.

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 destructive nature, the description provides all necessary context: the deletion effects, the user-confirmation requirement, the privacy rule about not exposing UUIDs, and the Proof of Funds impact. It is complete for an agent to safely and correctly 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 schema description for wallet_id is complete: 'Internal wallet UUID from get_wallet_summary. Do NOT show this ID to the user or ask them for it — look it up from the address they mentioned.' This fully explains the parameter's origin, purpose, and handling. The description reinforces this guidance.

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: 'Permanently remove a wallet from the authenticated user's account.' It specifies the action (remove), the resource (wallet), and the scope (permanent). This is easily distinguished from sibling tools like add_wallet or refresh_wallet_balance.

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 usage guidance: it instructs the agent to confirm with the user before calling, to refer to the wallet by address (not UUID), and to explicitly note the effect on Proof of Funds. It also implicitly indicates when to use the tool (when a wallet needs to be removed).

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?

Annotations already indicate this is a state-changing, non-idempotent operation, and the description adds valuable behavioral specifics: it creates a new session when a prior one is incomplete/denied/expired and returns a URL the user must open. This goes beyond what the annotations alone convey.

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: what the tool does, when a restart happens, and what the output is. The most important action is front-loaded and no filler is present.

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 role in the broader workflow, restart behavior, and output format. An output schema exists, so detailed return values are not required, and the parameter schema fully documents the inputs. An agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents force_new and id_number_required clearly. The description adds no parameter-level meaning, but it does provide relevant session context that indirectly supports force_new. 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 uses a specific verb and resource: 'Start or restart identity verification (KYC)', and grounds it in the RealOpen flow as 'the first setup step before... a crypto Proof of Funds letter'. This clearly distinguishes it from sibling tools like generate_proof_of_funds 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?

It clearly states when to use the tool: as the first KYC setup step, and when restarting after an incomplete, denied, or expired session. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough 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?

The annotations provide readOnlyHint:false, so the tool may mutate state, but the description does not disclose side effects, prerequisites, asynchronous behavior, or what happens after optimization. The 'all parameters are in UTC' note is a parameter-format detail, not an operation behavior. Without meaningful behavioral disclosure, the agent cannot anticipate the tool's effects.

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 text is short and front-loaded, but the first sentence merely restates the tool name, and the second sentence is an irrelevant detail about timezone. It is concise in length but not in value; the space is not used to clarify anything important about 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?

For a tool with nine parameters, no output schema, and no meaningful annotations, the description is severely incomplete. It lacks the parameters' purposes, return behavior, side effects, and guidance for alternatives. An agent cannot reliably construct a correct call or interpret the result from this definition.

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 0%, yet the description mentions none of the nine parameters and gives no meaning for target_return, risk_tolerance, time_horizon, constraints, etc. The note 'no timezone parameters' does not explain any parameter semantics. The description completely fails to compensate for the empty parameter descriptions.

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 verb ('Optimize') and a resource ('investment portfolio'), so it is not a pure tautology. However, it does not explain what optimization means in this context (e.g., rebalancing, target returns, risk constraints), making the purpose vague. It also does not differentiate this tool from the sibling get_portfolio_* tools beyond the word 'optimize'.

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?

There is no guidance on when to use this tool versus list_assets, get_portfolio_allocations, get_portfolio_risk, or get_portfolio_performance. The only usage-related statement is about timezone parameters, which does not help an agent decide when to invoke the tool. It neither names alternatives nor provides 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 provide no positive safety declarations, so the description carries the burden. It clearly states the tool does not move funds, the transfer is not a payment, and the verifier auto-matches the on-chain transaction against accepted assets. It stops short of describing side effects like updating verification status, but the core behavioral traits are well disclosed.

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 organized with labeled sections (HASH FORMAT, ASSET DETECTION, WHEN THE USER PROVIDES A TX HASH) and front-loads the core purpose. Some repetition exists around error relay and wallet_id lookup, but every section earns its place given the tool's complexity and common failure modes.

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, three parameters, and rich sibling context, the description is remarkably complete. It covers input formats, error handling, user-facing guidance, asset detection behavior, and the exact lookup workflow when wallet_id is unknown. With an output schema present, the absence of return-value details is acceptable.

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

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

Schema coverage is 100%, but the description adds substantial meaning beyond the schema: exact hash formats per blockchain, acceptance of block-explorer URLs with automatic extraction, the non-influential nature of asset_symbol, and the rule that wallet_id must be looked up and never shown to the user. This is far beyond a baseline schema-documented description.

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

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

States a specific verb and resource ('Submit a transaction hash for the dust/test transfer verification method') and differentiates it from verify_wallet_signature as 'the other way to prove ownership'. An agent can tell exactly what this tool does and how it differs from its sibling.

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 workflow guidance: when a Verify Wallet widget is visible, have the user paste the hash there; when no widget is present, call get_wallet_summary first to resolve wallet_id. It also names the alternative verification method and warns against exchange reference IDs, giving clear conditions for rejection.

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