TokenBank — tokenized real-world assets

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the comparison axes (yield, risk, custody, KYC gates, etc.), which is genuine behavioral context about what the output emphasizes, though it does not mention the six-instrument cap.

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 dense sentences with zero filler, and the comparison scope is front-loaded before the alternative-call 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, annotations, and a fully documented single parameter, the definition gives an agent everything needed to invoke it. The only unwritten detail is the maxItems=6 limit, which the schema already enforces.

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 even supplies a format example, so the single parameter is fully documented structurally. The description's 'two or more instruments' restates minItems=2 and adds no syntax 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 (compare/put side by side) and resource (instruments) and enumerates the exact fields compared, so the agent knows precisely what it returns. It is clearly distinguishable from siblings like get_product_details or compare_tokenized_access.

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 names the trigger ('X vs Y' questions) and the alternative to avoid ('instead of calling get_product_details repeatedly'). This routes the agent correctly without any 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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real value: it enumerates the response fields, clarifies that perps carry 'no ownership', warns that targetArea is not an eligibility check, and states counts come from the response rather than the prose.

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?

Dense and front-loaded: the core purpose and use cases lead, with caveats trailing. It is on the long side and the 'do not quote a figure from this description' meta-instruction adds bulk, but nearly every sentence carries routing or behavioral 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 an output schema present and annotations covering safety, the description need not restate return structure, yet it still clarifies semantics an agent would otherwise guess at (perps lack ownership, targetArea is not eligibility). Nothing needed 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?

Schema coverage is 100%, so the schema already documents limit, offset, sector, industry and query format. The description only reinforces 'omit `query` to list every such security', adding marginal meaning beyond the structured fields — the baseline 3 when 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?

Names a specific verb (compare) and a precise resource (every token issued on a single security, plus its Hyperliquid perps), and distinguishes itself from siblings like compare_assets and find_tokenized_security by scoping to one underlying. An agent can identify the operation 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 concrete routing examples ('which tokenized versions of Apple exist?', 'where can I get NVIDIA on-chain, and at what cost?') and states that omitting `query` lists everything. It never names a sibling alternative or a when-not condition, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds one behavioral note — that it returns balanced trade-offs rather than the maximum yield — which is useful framing but thin for a tool whose whole value is the quality of its comparison output.

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 short sentences, front-loaded with the comparison scope. The second sentence ('honest trade-offs, not just the bigger number') is slightly promotional but does convey behavioral framing rather than being pure 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?

An output schema exists, so return values need not be described, and the single parameter is documented. What is missing is which instruments fall under 'low-risk, instant-access' and what dimensions the trade-off covers, which would help an agent set expectations.

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 single optional parameter bank_rate_pct is fully documented, including its default of 2.0. The description only alludes to the bank rate conceptually and adds no format, range, or unit detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (compare) and a narrowly scoped pair of resources: low-risk, instant-access crypto savings instruments vs a bank savings account rate. That resource scoping implicitly separates it from broader siblings like compare_assets or search_yield_products, though it never names an alternative to make the distinction explicit.

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 use case (evaluating a bank savings rate against crypto savings options) is implied by the phrasing, but there is no explicit when-to-use, when-not-to-use, or named alternative such as compare_assets. An agent can infer intent but gets no routing 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 read-only, idempotent, closed-world behavior, and the description adds what a caller cannot infer: matches are questions with the first sentence of a computed answer from the live dataset, plus URLs to cite and JSON endpoints. It doesn't mention ranking, fallback behavior when nothing matches, or result ordering, which is the remaining gap.

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 verb and purpose, and the example list is genuinely useful for calibration. It is a single dense run-on sentence in the second half, and the parenthetical guide examples could be trimmed without losing meaning.

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 output schema, the description carries the return-value burden and does so: matching questions, first sentence of the answer with live figures, cite URL, JSON URL, and matched guides with their own JSON URLs. Combined with annotations covering the safety profile, an agent has enough 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 coverage is 100% and both parameters (query, limit with default 3 and max 10) are fully documented there. The description's examples illustrate acceptable query phrasing but add no syntax or constraint detail beyond the schema, so the 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+resource ('Find TokenBank answer pages') for a natural-language question, and the concrete example queries make the resource unambiguous. It also implicitly separates itself from siblings by positioning this as the question-entry tool and the others as filters.

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?

'Use this first for a question a person would type; use the other tools to filter beyond it' gives a clear entry-point rule and an exclusion. It stops short of naming which sibling to reach for a structured filter, so the routing is directional rather than precise.

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/idempotent/non-destructive, so safety is covered; the description adds real domain behavior beyond that — the strict gating policy, the buy-vs-trade scope caveat, and the mint-gate/trading-gate distinction for real-world assets. It does not mention rate limits or result-set behavior, but the disclosure is substantive for a read 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?

Four sentences, front-loaded with the core definition, and each sentence carries distinct information (definition, gating nuance, strictness policy, scope caveat). Dense but not padded; a slight trim of the last sentence's framing would be possible.

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

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

An output schema exists, so return values and pagination (nextOffset) need not be restated, and the description fully covers the conceptual domain an agent needs to route and interpret the tool. Adequate and well-matched to the structured fields it sits alongside.

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 include_unverified, offset, limit, pillar, and min_yield_pct fields are all self-documenting. The description supplies the conceptual model (verified vs merely-unverified gates) that makes include_unverified interpretable, but adds no per-parameter detail beyond the schema. 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?

The description states a precise verb+resource and, unusually helpfully, defines what "permissionless" means here: secondary market with no KYC, held in a self-custody wallet, read from hand-verified gates. That sharply distinguishes it from siblings like find_tokenized_security or compare_tokenized_access. It stops short of naming an alternative tool to use instead, so it is clear but not fully sibling-differentiated.

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 conveys when the semantic fit applies ('strict by design — an instrument whose gate is merely unverified is excluded'), but the actual when-to-use instruction for the unverified case lives in the include_unverified schema field, not the description. No sibling tool or exclusion path is named in the description itself.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: that identical companies are issued multiple times by different issuers and are not duplicates, that sources differ in authority (issuer catalogues vs aggregator observations with no KYC gate or custody claim), that targetArea is audience description not eligibility, and that absent yield/minimum/risk fields are absent rather than zero.

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 and the core caveats are front-loaded before the long source enumeration, and the three numbered points are structured and information-dense rather than padded. It is long, but most of the length carries decision-relevant content for an identity-lookup 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?

An output schema exists, so return format needn't be explained, and the description still supplies the interpretive guidance the agent needs (multiple issuances, source authority tiers, empty-vs-zero semantics). Nothing needed to call or interpret 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?

Schema description coverage is 100%, so all six parameters (including enum values and pagination via offset/nextOffset) are already documented in the schema. The description adds only light framing (issuer comparison is the useful part, identity-data caveat) and no new syntax or format detail. 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?

Opens with a specific question the tool answers (does a tokenized version of a company/ETF/bond exist and from which issuer) and states the search keys (company name, ticker, ISIN). It is clearly distinguishable from siblings like search_yield_products or get_country_registers.

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 imperative: 'Use this BEFORE saying a stock is not available on-chain.' It also explicitly routes rate-bearing instruments to search_yield_products, and warns the agent to report the issuer rather than a bare existence claim. When-to-use and when-to-use-something-else are both stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing that the payload includes live counts and that each referenced guide carries a JSON URL — output characteristics not visible without an output schema. It stops short of noting payload size, caching, or whether 'live counts' are real-time, which keeps it at 4.

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 trigger condition is front-loaded in the first clause, and the middle sentence is a dense but information-bearing enumeration of the return payload. It is long and list-heavy, but each item maps to a distinct thing the agent needs to know before calling.

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 output schema, the description carries the full burden of explaining return values, and it does so item by item. Combined with the annotations covering the read-only/idempotent profile and the schema covering parameters, nothing an agent needs in order to select and 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?

Schema description coverage is 100%, so both parameters (limit, min_yield_pct) are already documented in the schema, making 3 the baseline. The description hints at the filtering behavior via "highest-yield wallet-only candidates" but adds no explanation of how limit or min_yield_pct shape that returned set.

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

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

The description names a specific resource (the agent buying guide) and enumerates exactly what it contains: six steps, purchase paths with live counts, permissionless asset classes, top wallet-only yields, guardrails, and linked guides. It is clearly distinguishable from siblings like get_purchase_steps, which it explicitly positions as the per-ticker follow-up.

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?

"Start here when building or running an AI agent or trading bot that buys tokens on its own" sets an explicit trigger condition, and the closing sentence routes the agent to get_purchase_steps for single-ticker detail. Both when-to-use and when-to-use-something-else are stated directly.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description does add genuine interpretive context the annotations cannot carry — that an entry is a licence/registration/approval, not proof of issuance, and that provider registers list companies rather than instruments. It does not mention pagination behaviour or data freshness, so it goes beyond annotations but not exhaustively.

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 the resource and scope, then moves to concrete use cases, then closes with the two caveats that matter most for correct interpretation. Every sentence carries distinct information; nothing is repeated from the schema or annotations.

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 structure need not be described. For a zero-required-parameter, 5-param search tool over a specialised domain, the description supplies scope, invocation recipes, and the semantic caveats an agent needs to avoid misusing the results. Nothing material is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description still adds meaning by showing how parameters combine in practice ('pass query without country' for cross-jurisdiction lookup, kind=issuance for the list-of-issues case). It does not explain the 'candidate' vs confirmed distinction beyond what the enum already states, so it does not fully supplant 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 resource ('Official registers of tokenized assets and digital-asset firms') with scope ('any of 250 jurisdictions') and enumerates what the data contains (supervising authority, public registers, the entries themselves). This is clearly distinguishable from the sibling market/asset-search tools, which deal with prices and instruments rather than regulatory registers.

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 three concrete invocation patterns ('what is registered in Lithuania', 'is firm X licensed anywhere' with query-but-no-country, and kind=issuance for 'which countries publish a list of token issues'). It also states explicit exclusions: entries are not proof of issuance and provider registers must never be counted as tokens, which prevents two plausible misuse modes.

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). The description goes further by disclosing the dataset's coverage limits — that ~$9bn sits in unindexed markets and that India/Vietnam/Indonesia/Thailand have no local-currency stablecoin — which is material context for interpreting results. It does not, however, cover return mechanics such as pagination.

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 routing instruction is front-loaded, but the body drifts into extensive market trivia (¥1tn consortium chain, eighteen banks, $2.2bn in 2026, the 4 February 2027 date) that is engaging yet marginal for deciding whether to invoke the tool. The core guidance could have been delivered in a third of the length.

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

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

With an output schema present, return values need no explanation, and the annotations carry the safety profile. The description supplies the usage conditions and coverage caveats an agent needs, missing only minor operational detail such as result volume or pagination for the all-markets case.

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 in the schema. The description's only parameter guidance ('Omit `country` for every market') repeats the schema's own text and adds no new syntax or format detail, so the baseline of 3 applies.

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

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

The opening clause states a specific verb and resource — which countries the dataset can and cannot see into, and why. It is clearly distinguishable from siblings like get_market_stats and get_country_registers, and it explicitly claims the 'what is tokenized in Japan/Korea' question.

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 names the trigger condition explicitly ('Call this before stating what a market holds, or before quoting any total as if it were the world') and redirects from a general search to this tool for country-level tokenization questions. Both when-to-use and the alternative approach are stated.

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 closed-world, so the safety profile is fully covered. The description adds only one trait beyond that — that the figures carry a freshness dimension — while the rest of the text restates return content that the existing output schema already documents.

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

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

Two sentences, zero filler. The content enumeration comes first and the usage cue is front-loaded as the final sentence, so an agent gets the payoff before the instruction.

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

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

With a rich annotation set, no parameters and an output schema present, the description only needs to say what the tool is for and when to reach for it. It does that, but omitting any contrast with the sibling get_market_coverage leaves a real selection gap in a crowded family of coverage-related tools.

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 no parameter semantics to explain; the baseline for a 0-param tool is 4. The description correctly implies the tool is parameterless by framing the output as a global dataset shape rather than something that is queried or filtered.

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

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

The description names a specific resource (dataset statistics) and enumerates exactly what is counted: instruments by pillar, category and risk, plus KYC-free instruments and freshness. It is clear what the tool returns, though it never distinguishes itself from the sibling get_market_coverage, which an agent could easily confuse it with.

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 one concrete use case ('ground a claim about coverage before making one'), which is better than nothing. However, it names no alternative and no when-not condition, and the potentially overlapping sibling get_market_coverage is not mentioned, so the routing decision is left partly 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 already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds the useful case-insensitivity trait and enumerates returned fields, but says nothing about behavior for an unknown ticker or rate limits.

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?

A single front-loaded sentence naming the key, the scope, the case-insensitivity caveat and the field inventory. No filler, no restatement of the title.

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 explained, and annotations carry the safety profile. The field list plus case-insensitivity note makes it actionable; only the missing-ticker/failure behavior is 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?

With 100% schema coverage the schema already carries the parameter and its examples (USDY, stETH, PAXG), so baseline is 3. The description adds genuine semantic value by stating the lookup is case-insensitive, which the schema does not mention.

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 resource ('one instrument') and retrieval scope ('full record'), with the lookup key named. It implicitly distinguishes itself from the search_*/compare_* siblings by scoping to a single ticker, though it never names an alternative directly.

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

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

Usage is only implied: an agent can infer this is the tool to call once it already has a ticker and wants depth. There is no explicit statement of when to prefer it over search_yield_products or compare_assets, nor any prerequisite or error 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, and the description reinforces this with 'it does not build, sign or send a transaction' and scopes out eligibility. It adds genuine behavioral context beyond annotations by disclosing data limits ('where researched', sourced 'from issuer documentation'), which tells the agent results may be partial. It does not mention latency or data freshness beyond that 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?

Purpose is front-loaded in the opening clause, but the remainder is a single run-on sentence that crams seven or eight parallel content lists into one breath. It is dense and scannable only with effort; breaking the enumerated contents into a short structured list would cost nothing and gain clarity.

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

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

An output schema exists, so return-value shape need not be restated, and the description instead characterizes the substance of the response (purchase path type, gates, ordered steps, guardrails, exit terms). Combined with read-only annotations and fully documented parameters, an agent has enough to decide whether to call it and what to expect.

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

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

Schema coverage is 100% with only two parameters, both documented in the schema itself (ticker with examples, optional amount_usd described as only affecting the approval-step wording). The description adds no parameter-level guidance, but the schema already carries the burden, 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?

The description states a concrete deliverable: the step-by-step purchase path for one instrument, including KYC gates, issuer route, venues, exit terms, ordered steps and guardrails. It is clearly not a transaction executor, distinguishing it from write tools. It does not name a specific sibling (e.g. find_permissionless_assets or get_product_details) as the alternative, so sibling differentiation is only implied through the phrase 'it does not say who may buy.'

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

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

Usage is implied by the enumeration of contents — an agent should call this when it needs the procedure for buying a given ticker. There is no explicit when-to-use/when-not-to-use statement nor a named alternative tool for the related questions it disclaims (who may buy, executing the trade).

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/closed-world, so the safety profile is covered. The description adds useful domain context by defining net rental yield (annual net rent / tokenized property value), but says nothing about pagination behavior or result scope beyond that.

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

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

Two sentences, zero filler, with the identity of the tool front-loaded and the usage cue second. 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?

An output schema exists, so return values need not be restated, and the description explains the headline computed metric. The only small gap is that pagination is left entirely to the schema rather than hinted at in prose, but nothing needed to call 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?

Schema coverage is 100%, so the schema already documents every parameter including the offset/nextOffset walk and defaults. The description only alludes to yield/price spread and adds no syntax or format detail beyond the schema. 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?

Specific verb ('drill into') plus precise resource ('individual tokenized US rental properties behind the REALT entry'), and it enumerates the distinguishing fields (net yield, token price, monthly rent, occupancy). An agent can separate this from the issuer-level or generic product siblings without opening a 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 an explicit trigger: 'when someone asks which specific tokenized property to buy, or for the yield/price spread within one issuer.' That implicitly points away from the broader aggregate/view tools, but it never names the alternative or states when not to use it.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the tier behavior: curated rows carry yield/minimum/risk, imported rows carry identity/classification only. That is genuinely useful beyond the annotations, though the summary character of results ('compact records') is only lightly explained.

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 front-loaded sentences; the default-tier constraint and the sibling pointer are never buried. Slight redundancy with the schema's own tier description, but no wasted sentences.

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 restated; the description still characterizes results as compact and routes to get_product_details for the full record. With 100% schema coverage and full annotations, an agent has everything needed 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 100%, so the schema already documents tier, offset/nextOffset paging, risk scale and limit semantics. The description reinforces the default-tier behavior but adds no syntax or format meaning beyond what the schema states.

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 ('Search and filter TokenBank's instruments for earning yield') plus the scope of the default result set. It also names the sibling used for full records (get_product_details), so the agent can separate it from alternatives without opening a 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?

Explicitly says the curated tier is the default and is the only one that answers yield questions, while imported/all are for identity questions and 'never for yield rankings.' The alternative (get_product_details) is named with its condition of use.

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