mcp-server

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

Annotations only declare idempotent/non-destructive/open-world; the description adds substantial behavior the annotations cannot convey — the inline Verify Wallet widget, cancelled-call/consent-dismissal handling, stale-output warnings, zero-balance stealth-address caveats, and chain-specific verification mechanics (ERC-1271, dust-transfer chains). This is far beyond what structured fields 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?

Front-loaded correctly with a clear opening sentence and labeled sections (CANCELLED-CALL HANDLING, POST-VERIFY RE-CHECK, PRESENTATION, EVM CHAIN NOTE, etc.) aid scanning. However it is heavily oversized, with per-chain guidance (Zcash, Dogecoin, ETC, BNB) that could live in reference material rather than the selection-time description.

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?

An output schema exists, so return values need not be described, and the description still covers the edge cases an agent must handle: retries, verification state staleness, custody limitations, unsupported address types, and chain-specific constraints. Nothing needed to invoke or interpret results 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 single required address parameter is 100% schema-covered, so baseline is 3, but the description materially enriches its meaning: addresses must be public, 0x addresses span multiple EVM chains, Zcash must be transparent (t1…/t3…), and D… vs 9…/A… Dogecoin addresses change the flow. That is real semantic value over the schema's one-line 'public wallet address to add'.

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?

Opens with a specific verb+resource+outcome: submit a public wallet address so RealOpen verifies ownership and counts holdings toward a Proof of Funds letter. It further distinguishes itself from siblings by name (verify_wallet_signature / verify_wallet_transfer run inside the widget) and by function (retry path for FAILED/unverified wallets). An agent can tell exactly what this does and how it differs from the surrounding 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?

Gives explicit when-to-use rules (first add, retry after FAILED/unverified, after widget verification always call get_wallet_summary first) and when-NOT-to-use routes (exchange-custodied assets → get_faq; shielded Zcash rejected; ETC counts for proof of funds but is not a settlement asset). Alternatives are named and conditions spelled out.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this explicitly ('does not move, sell, convert, or reserve any crypto'). It adds substantive behavior beyond the annotations: verified-only counting, the fact that identity or wallet verification may be incomplete, and the estimation caveat.

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

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

Five sentences but front-loaded with the core purpose and no filler; each clause carries information (scope, exclusions, caveat). Slightly long for a two-parameter read tool, but nothing is wasted.

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?

An output schema exists and annotations cover the safety profile, so the description need not detail return shape. It still tells the agent what comes back (coverage plus incomplete items) and the verified-only constraint, leaving nothing material 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 both parameters are already documented, including the omit-to-use-saved-price behavior. The description only adds the framing that asset 'narrows to one asset,' which largely duplicates 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?

States a specific verb and resource ('checks whether the user's VERIFIED crypto appears to cover a property price') and scopes the comparison to verified wallets only. An agent can immediately distinguish this from generate_proof_of_funds or get_wallet_summary.

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

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

Gives an explicit use case ('can my Bitcoin cover a $2 million home?'), a sequencing rule ('before generating a Proof of Funds letter for a specific amount'), and the exclusions that matter ('Unverified wallets never count'). It also names what it is not ('not a loan decision').

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?

Goes well beyond the annotations: states preconditions and that it reports what is missing, discloses the 30-day private download link, explains that each call regenerates at current values while a repeat within minutes returns the same report (matching idempotentHint=true), and draws explicit scope boundaries (not a loan decision/pre-approval, does not move, convert, or reserve crypto). This is the kind of operational and safety context annotations cannot carry.

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

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

Front-loads what the report is, then prerequisites, then return behavior, then limits — a sensible information hierarchy. The prose is dense with no filler sentences, though it is on the longer side for a no-parameter call.

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?

An output schema exists and the description still covers preconditions, regeneration/idempotency nuance, link lifetime, and explicit non-goals. Nothing an agent needs to decide whether and how to call this tool 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 takes zero parameters, so per the rubric the baseline is 4. The description adds no parameter discussion, which is appropriate since there is nothing to document and the schema is empty.

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 ('Creates the user's RealScore Report') and then defines precisely what the artifact is and contains (identity, verified wallets, holdings, balance history, conversion adjustment). An agent can tell what it produces without opening the schema. It never names the closest sibling, generate_proof_of_funds, so explicit sibling differentiation is missing.

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

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

Gives clear triggering context ('the asset verification document a buyer gives a mortgage lender when the down payment or reserves come from crypto') plus hard prerequisites (verified identity, at least one verified wallet). What is absent is any when-to-use-this-vs-that guidance relative to generate_proof_of_funds or the other wallet/verification 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 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 flag destructiveHint=true/openWorldHint=true/idempotentHint=true, and the description goes well beyond that by explaining the verified-vs-pending binding states, that nothing counts toward Proof of Funds until verification, the automatic rescan that follows linking, the binding-failure error case, and hard safety rules about private keys and seed phrases. This is unusually rich behavioral disclosure for a mutation tool.

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 most decision-critical facts (chain restriction, verb, effect) are front-loaded, and ALL-CAPS headings give structure. But the description is very long, with wallet-export instructions and multisig guidance that arguably belong in get_faq/get_snippets siblings, and several clauses restate the same behavior, so it is dense rather than tight.

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 rich annotations, a full input schema and an existing output schema (xpub_scan results), the description covers the remaining gaps: supported chains, unlink behavior, pending verification lifecycle, binding-failure recovery, and the multisig exception. An agent has everything needed to call 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 coverage is 100%, so the schema already documents all three parameters; however, the description adds real meaning beyond it, including the multisig output-descriptor/Unchained-config alternative for xpub, the warning that a lone Ypub/Zpub is one cosigner, and that unlink reverts balance to the verified address.

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 (link/remove) and resource (extended public key / xpub) and immediately scopes supported chains (BTC, Zcash transparent, Dogecoin) plus the effect on balance and Proof of Funds. It is clearly distinguishable from siblings like add_wallet and verify_wallet_signature, which address wallet creation and signature verification rather than key linking.

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 trigger conditions are given: use when a verified BTC wallet shows less than expected, when get_wallet_summary or refresh_wallet_balance returns full_wallet_hint, or when the user mentions a hardware/HD wallet. It also names the sequencing (offer right after add_wallet) and the conditions under which to use unlink or supply a multisig descriptor instead of a single xpub.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the OAuth token revocation, which implies subsequent calls will fail until re-authentication - a consequence the agent would not infer from the hints alone.

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

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

Two sentences, no filler, with the action front-loaded and the usage condition following. Every clause carries information.

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

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

With no parameters, full schema coverage, annotations covering the safety profile, and an output schema handling return values, the description contains everything an agent needs to select and invoke 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly avoids inventing any parameter discussion.

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: signs out of the RealOpen MCP session and revokes the OAuth token. No sibling tool performs session teardown, so it is clearly distinguishable from the wallet, status, and informational 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?

Explicitly says to use it when the user wants to switch accounts or disconnect, giving clear triggering conditions. It does not name an alternative path or state when not to use it, which keeps it just 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantive context: the 'never ask for a private key or seed phrase' constraint, how each chain verifies (public address, signed message, dust transfer, xpub), and that read-only means it does not move/sell/convert/hold crypto. This goes well beyond the structured fields.

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?

Purpose is front-loaded in the first clause, followed by routing, workflow, and safety constraints. It is dense and long, but nearly every sentence carries distinct operational information; only the exhaustive list of panel contents 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?

An output schema exists and annotations are rich, so return values need no explanation. The description covers routing, the blocked_request escape hatch, chain-specific verification behavior, and the no-secrets rule, which is everything an agent needs to invoke this panel-opening 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%, so the baseline is 3, but the description adds semantic framing: 'Pass what the conversation has established (target_price_usd, asset, workflow)' and explains the verify_wallet workflow's meaning and the purpose of blocked_request. It doesn't detail wallet_id or the full enum set, keeping it just 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?

States a specific verb and resource ('Opens the RealOpen panel beside the current conversation') and immediately differentiates from the sibling open_realopen by noting it is not the full-screen sidebar. The enumerated panel contents make the scope 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?

Explicitly routes between this tool and open_realopen, explains when to pass workflow='verify_wallet', and instructs setting blocked_request when the user asks for transfer/sell/trade/convert/hold. This is explicit when-to-use and when-to-alternative 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 establish readOnly, idempotent and non-destructive, yet the description still adds real value: it previews the view contents (connection state, setup progress, verified buying power, proof-of-funds status, one recommended next step), specifies a privacy behavior (wallets summarized, never full addresses), and explicitly disclaims custody ('nothing here moves, sells, converts, or holds crypto'). Repeating 'Read-only' is redundant with readOnlyHint, keeping this from a 5.

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

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

Front-loaded with the action, then trigger conditions, then view contents, then safety scope. Efficient multi-sentence structure, though the closing crypto-custody sentence is somewhat defensive and partially redundant with the readOnly annotation and the preceding 'Read-only' statement.

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 needn't explain returns, and annotations cover safety, so what remains — when to open it and what the user will see — is covered. The only gap is the undocumented realscore_report workflow value, leaving one invocation path unaddressed.

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 enum is self-documenting, so the baseline is 3. The description adds workflow intent ('open straight into one workflow') but enumerates only buying_power, verify_wallet, and proof_of_funds, silently omitting the realscore_report value that the schema actually accepts.

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 ('Opens the RealOpen home, the full-screen app in the ChatGPT sidebar') and immediately scopes what the resulting view shows. An agent can distinguish it from panel-level siblings like open_buying_power_panel because this is the home/overview entry point.

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

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

Gives explicit trigger conditions ('Use it when the user asks to open RealOpen, open the RealOpen app or sidebar, or see an overview of where they stand'), which is strong positive guidance. It stops short of disambiguating against siblings such as open_buying_power_panel, which competes for the same buying-power intent and is only indirectly covered by the workflow parameter.

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?

Despite annotations already covering safety (idempotent, non-destructive), the description adds substantial behavior beyond them: the empty-fetch safeguard that preserves existing balances and returns status=no_change, the no_change composition retention, plus linkage semantics for linked_addresses and xpub-linked scans. This is exactly the mutation/edge-case context annotations cannot 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 purpose is correctly front-loaded, but the body then enumerates many response fields (xpub_linked, full_wallet_hint, transparent_only_hint, liquid_usd/staked_usd) that duplicate the output schema, making it dense and longer than needed. The conditional hints are operationally useful but the field enumeration 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 single-parameter refresh tool with rich downstream interpretation, the description covers the critical failure modes an agent would otherwise get wrong: zero-balance privacy addresses, BTC/ZEC/DOGE full-wallet vs transparent-only cases, and staked-vs-liquid value. Nothing essential to correct handling 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?

Only one parameter (wallet_id) exists and schema coverage is 100%, including the 'do not show this ID to the user' guidance. The description adds nothing about the parameter, so the baseline 3 applies — the schema carries the load entirely.

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 names a specific verb (re-fetch/update) and resource (on-chain asset balances for an existing wallet) plus the downstream purpose (Proof of Funds ceiling). An agent can distinguish this from get_wallet_summary (read-only view) and refresh_wallet_verification without inspecting schemas.

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

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

It gives an explicit trigger: 'Use when the user says their balance looks stale, wrong, or zero after a recent on-chain change.' That is clear context for invocation, but it never names the nearest alternative (refresh_wallet_verification) or states when-not-to-use this tool, 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?

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 declare destructiveHint=true and idempotentHint=true, and the description meaningfully expands on them: it explains it 'may replace or clear prior planning details,' 'stores planning details only,' and enumerates non-effects (no wallet/identity/document/fund changes, no crypto movement, no Proof of Funds letter). This is rich behavioral context beyond the annotation flags.

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?

Opens with the core effect and keeps the trigger and clearing rules up front; the exclusion list that follows is long but each clause earns its place by preventing misrouting. Slightly dense but not padded.

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, return values need no explanation, and the description covers purpose, trigger, null semantics, and the full set of things this tool does not do. An agent has everything needed 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 all four parameters (asset, workflow, wallet_id, target_price_usd) are already documented. The description restates the same fields and the null-clears-value convention without adding format or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (saves) and resource (planning details: property price, crypto asset/wallet, workflow) and ties it to a concrete effect (sidebar/conversation panel staying in step). It also differentiates from siblings by declaring what it is not (not a wallet, identity, document, funds, or offer mutation).

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 trigger: 'Call it when the user states or changes any of these,' plus the null-clearing rule. It also lists what the tool must not be used for, implicitly routing agents to the wallet/funds/offer siblings, but it never names a specific alternative tool the way a 5 would.

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?

Adds real behavioral context beyond the annotations: it returns a hosted verification URL the user opens in a browser, it re-creates sessions after denial/expiry (consistent with idempotentHint=false), and it warns not to collect identity details in chat. It does not cover auth/permission requirements or rate limits, so not a 5.

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

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

Three sentences, front-loaded with the core action and workflow position, then restart semantics, then the security caveat. Every sentence is relevant, though the middle sentence overlaps somewhat with what the schema says about force_new.

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, return values need not be explained, and the description still covers flow position, restart behavior, and safe handling of the hosted URL. Nothing an agent needs to call this 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?

Schema description coverage is 100% and the single force_new parameter is fully documented there, so baseline is 3. The description's mention of restarting after incomplete/denied/expired sessions loosely reinforces force_new's purpose but adds no syntax or format detail beyond the schema.

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

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

States a specific verb+resource ('Start or restart identity verification (KYC)') and immediately places it in the workflow as 'the first setup step before RealOpen can issue a crypto Proof of Funds letter.' An agent can distinguish it from siblings like generate_proof_of_funds or refresh_wallet_verification without opening the schema.

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

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

Gives clear usage context: it is the prerequisite step for a Proof of Funds letter, and a new session is created if a prior one was incomplete, denied, or expired. It does not name an explicit alternative tool or a when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the state-changing, non-idempotent nature is covered. The description adds meaningful context beyond that: the user must sign the exact message issued by add_wallet, the widget may invoke this tool itself, and the signature must be the full hash. It does not spell out failure modes or what verification state changes, which keeps it short of a 5.

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?

Purpose and prerequisite are front-loaded, then usage is split into clear conditional branches. It is verbose, and the closing anti-pattern warning ('Do NOT respond with...') is somewhat defensive, but every sentence carries routing or workflow information rather than 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 available the description need not explain returns, and annotations cover the safety profile. Together with the branching workflow and prerequisite message, an agent has everything needed to invoke this tool correctly in both widget and conversational paths.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine operational meaning: it explains how an agent obtains wallet_id (match the user's stated chain/address against get_wallet_summary's per-wallet line) and that the ID must never be surfaced to the user. That is procedural context the schema field description alone does not convey.

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 signed message to verify wallet ownership) and frames it against the sibling verify_wallet_transfer by calling itself 'one of the two ways RealOpen verifies a wallet'. An agent can distinguish it from the transfer-based sibling without reading either schema.

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

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

Explicit branching guidance: use the widget when visible, otherwise call get_wallet_summary to resolve wallet_id then call directly. It also names the prerequisite (the exact message from add_wallet) and the refresh/add siblings that create the widget context. Nothing about when-to-use is left to inference.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false. The description adds substantial context beyond them: the tool moves no funds, the transfer is not a payment, it auto-matches every accepted asset so asset_symbol is irrelevant, and it documents the invalid_transaction_hash_format rejection path and the assistant_guidance relay behavior. That is genuine behavioral disclosure the annotations cannot 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?

The format spec and error-handling sections are front-loaded and information-dense, and nearly every sentence covers distinct edge cases (hash formats, explorer URLs, exchange ref IDs). It is long, and the closing scolding about not saying 'I'd need to work out the wallet_id' is the one sentence that reads as padding against a specific past failure rather than general 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?

With an output schema present, the description needn't explain return values, and it doesn't. Combined with 100% schema coverage and annotations, it covers prerequisites, invocation flow, accepted input formats, error semantics, and asset matching — everything an agent needs to call this 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 already 100%, so the 3 baseline applies; the description nonetheless reinforces the key semantic point that asset_symbol is an audit hint only and does not affect matching, and that wallet_id is looked up by the agent rather than asked of the user. It duplicates the schema text rather than extending it, but the workflow framing (auto-match across assets) adds real meaning to 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 opening sentence names a specific verb (submit a transaction hash), the mechanism (dust/test transfer verification), and the goal (proving wallet ownership so balance counts toward a Proof of Funds letter). It explicitly contrasts itself with the sibling alternative ('the other way to prove ownership'), so an agent can pick it over verify_wallet_signature without opening either schema.

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

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

Gives prerequisites (the user must already have sent a transfer to the deposit address from add_wallet), states the alternative method, and exhaustively routes the two invocation paths — widget-visible vs no-widget (call get_wallet_summary first, then this tool). It even pre-empts a specific failure reply the agent might otherwise give. This is explicit when-to-use guidance.

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