TokenBank — tokenized real-world assets

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

Annotations (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false) already carry the safety profile, so the bar is lower. The description adds genuinely useful operational context: it is a multi-instrument, side-by-side comparison over a defined field set rather than a single-record lookup, which is not derivable from the annotations. It stops short of stating cardinality limits or partial-failure behavior, hence 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?

Two sentences, front-loaded with the action, then the routing guidance. The field enumeration is long but every item is decision-relevant information, not 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 annotations covering safety, 100% schema coverage on the single parameter, and an output schema present, the description need not explain return values or the input format. It supplies the one thing structured data cannot: why and when to choose this over repeat calls to get_product_details.

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

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

One parameter with 100% schema description coverage, including a concrete example and min/maxItems constraints (2-6). The description's 'two or more instruments' only echoes what the schema already declares (minItems: 2), so it adds no meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb ('put two or more instruments side by side') and resource, and enumerates the exact comparison fields (yield, risk, minimum, custody, KYC gates, target/area, issuer, verification date). It also names the sibling it replaces (get_product_details), so an agent can separate it from the other compare_* tools 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 scopes usage to "X vs Y" questions and names the alternative (get_product_details repeatedly) that this tool is meant to supplant. The when-to-use and the reason to prefer it over a sibling are both stated, leaving nothing 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 establish the safe, read-only, idempotent, non-open-world profile, so the description is not obligated to restate them. It adds real behavioral context: that perps carry no ownership, that targetArea is descriptive of issuer intent and not an eligibility check, and a warning not to quote figures from the description since the response holds exact counts. The only blemish is that it then quotes 'seven' tokens for Apple while warning against doing exactly 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?

The purpose is front-loaded and most sentences do work, but the prose is dense and meandering, with the self-referential count caveat occupying significant space and partially undercutting itself. It is informative without being 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?

An output schema exists and carries return values, and annotations cover the safety profile, so the description only needs to explain scope, comparative content, and response semantics. It does all of that, including what the compared fields represent and what targetArea does and does not mean.

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

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

Schema description coverage is 100%, with enums and pagination semantics (offset/nextOffset, limit default) already documented in the schema, so the baseline is 3. The description's only parameter-adjacent guidance ('omit query to list every such security') repeats what the schema already states for query, and it adds no meaning for limit, offset, sector, or industry.

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 precise verb (compare) and resource (a multi-issuer security's tokens and its Hyperliquid perpetuals) and enumerates what is compared: issuer, structure, KYC gates, custody, chain, target/area, fees, funding, leverage. The scope selector 'tokenized by more than one issuer' implicitly separates it from generic find/search tools, but no sibling such as compare_assets or find_tokenized_security is named, so sibling differentiation is inferred rather than stated.

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 trigger queries ('which tokenized versions of Apple exist?', 'where can I get NVIDIA on-chain, and at what cost?') and an explicit default action ('Omit query to list every such security'). There is no statement of when NOT to use it or which sibling to prefer instead, so it stops short of full 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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds a qualitative behavioral note about output nature ('honest trade-offs'), which is useful context but not a deep disclosure of rate limits, data freshness, or computation scope. It doesn't contradict annotations but also doesn't add much beyond 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?

Two sentences, front-loaded with the core comparison and followed by a concise qualifier. Every sentence earns its place; there is no redundancy or 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?

The tool has an output schema, so the description needn't explain return values. However, with only one parameter and full schema coverage, the description is somewhat sparse on contextual guidance, such as what 'low-risk, instant-access' entails or how the comparison is computed. It is adequate but leaves gaps in routing and 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%: the single parameter bank_rate_pct is fully described in the schema, including default. The description does not add semantic meaning about how this parameter is used (e.g., whether it's annual percentage yield, compounding, etc.). Baseline 3 is appropriate 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?

The description states a clear comparison task: contrasting low-risk instant-access crypto savings instruments with a typical bank savings account. It is specific about the resource set but doesn't explicitly differentiate from sibling tools like compare_assets or compare_tokenized_access, so the agent might still wonder which comparison tool to pick.

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

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

There is some implied guidance ('honest trade-offs, not just the bigger number') which hints at the philosophical stance, but no explicit when-to-use or when-not-to-use conditions, nor are any alternatives named. The description does not tell the agent under what circumstances this tool is preferable to compare_assets or search_yield_products.

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, so the bar is low, yet the description adds real behavioral context beyond them: default exclusion of unverified gates, the mint-vs-secondary-trade gate distinction, and a scoping disclaimer that the result says nothing about who may legally buy. It does not discuss pagination or result shape, but those are covered by schema and output 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?

Four dense sentences, front-loaded with the defining property before the mint/trade nuance and the legal disclaimer. Each sentence carries information — the gate distinction, the strictness rule, and the scope limitation — with no filler, though the prose is heavier than a typical filter tool warrants.

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 full schema coverage, an output schema, and rich annotations, the description only needed to convey what the filter means and where its boundaries lie — and it does so thoroughly, including the strictness default and the legal caveat. Nothing needed to invoke 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 description coverage is 100%, so the baseline is 3. The prose clarifies the concept behind include_unverified and the gate semantics, but adds no parameter syntax, formats, or defaults beyond what the schema already documents (limit, offset, pillar enum, min_yield_pct).

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 pins down a precise resource set — instruments whose secondary-market gate requires no KYC and that a self-custody wallet holds — and distinguishes that property from mint-level permissioning. It never states the operation in verb form ('find/list/return'), leaving the agent to infer that a collection is returned, but the defining criteria are unusually specific and separate it from siblings like find_tokenized_security.

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?

Strong context on inclusion semantics: 'Strict by design — an instrument whose gate is merely unverified is excluded,' and the explicit rule that include_unverified is only for 'what MIGHT be open, never to answer what IS open.' It does not route the agent among siblings (find_tokenized_security, search_yield_products) or state prerequisites, so it stops short of explicit when/when-not against alternatives.

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

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

Annotations already cover the read-only/idempotent safety profile, and the description goes well beyond them: sources differ in AUTHORITY (issuer catalogues vs. aggregated observation rows with no KYC gate and no custody claim), targetArea is a stated audience and never an eligibility check, and identity fields are absent rather than zero. This is exactly the extra behavioral context 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?

Front-loaded with the core question, then the scope, then the alternative. The three numbered points are long but each carries decision-relevant content; the third point partly restates output semantics that the output schema already covers, which is the only real padding.

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 need not explain return values, and it still covers scope, authority tiers, issuer multiplicity, pagination hints via the schema, and sibling routing. 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 enum params (line, issuer) are already documented in the schema, so baseline 3 applies. The description reinforces issuer semantics conceptually ('Report the issuer, not just that the token exists') but adds no syntax, defaults, 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 ('Does a tokenized version of a given company, ETF or bond exist, and from which issuer?') and enumerates the tiers it searches, so the agent can distinguish it from search_yield_products and the compare_* siblings immediately.

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 usage: 'Use this BEFORE saying a stock is not available on-chain' and 'For instruments that do carry a comparable rate, use search_yield_products instead.' Both the when-to-use and the alternative-with-condition are stated outright.

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, so the safety profile is covered. The description adds substantial behavioral context: the dataset excludes markets other Western aggregators miss, gives examples of hidden markets, explains legal-recognition phasing and venue-level retail caps, and clarifies that the tool returns coverage along with reasons. This goes well beyond the annotations.

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

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

The description is front-loaded with purpose and ends with a clear usage instruction and omit-country reminder. However, the middle section contains lengthy country-specific facts (Japan's ¥1tn consortium chain, Korea's 2027 legal recognition, India's lack of stablecoins) that are illustrative but not necessary for an agent to select and invoke the tool correctly.

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 lightweight 2-parameter schema, 100% parameter coverage, an output schema, and annotations covering safety, the description is complete enough. It explains what the tool reveals, why it matters, when to call it, and how to request all markets by omitting country. Nothing needed to invoke 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 description coverage is 100%, and both country and readable_only are already well documented in the input schema, so the baseline is 3. The description reinforces the omit-country behavior and gives country examples, but it does not add meaningful semantic detail for readable_only beyond what the schema already 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?

The opening phrase 'Which countries this dataset can see into, which it cannot, and why' clearly identifies a specific verb, resource, and unique scope. It distinguishes the tool from a 'general search', but does not explicitly name or contrast sibling tools like get_market_stats or compare_tokenized_access, so sibling differentiation is only implicit.

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

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

The description gives strong when-to-use guidance: 'Call this before stating what a market holds, or before quoting any total as if it were the world.' It also says the tool should answer country-tokenization questions 'rather than from a general search.' However, it does not name specific sibling tools or state when not to use this tool in favor of one of them.

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 one genuinely useful behavioral detail, that results include freshness of the figures, but says nothing about snapshot timing, cache behavior or whether the numbers are point-in-time or rolling.

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

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

Two sentences, front-loaded with the dataset-shape framing and closed with the usage rule. The colon-and-list construction is dense but every element carries information; no filler 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 described, and with no parameters the schema burden is nil. The description covers what is aggregated and the call-to-action context; the main gap is that it never scopes the dataset (which markets, which snapshot date) covered by the stats.

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. Nothing in the description contradicts or complicates the empty 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?

It names a specific resource and enumerates what it reports: instrument counts split by pillar, category and risk, KYC-free count on the secondary market, and figure freshness. That is clearly distinguishable in kind from siblings like compare_assets or search_yield_products, though no sibling is named explicitly.

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 to ground a claim about coverage before making one" gives a concrete usage context, which is more than most stats tools offer. It stops short of naming a specific alternative (e.g. get_market_coverage) or stating 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable context: case-insensitive ticker matching and the specific fields returned (yield, risk, custody, availability, how to buy, source link, verification date). It also confirms this is a single-record retrieval, not a list operation. No contradictions with annotations.

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

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

The description is one concise sentence, front-loaded with the primary purpose ('Full record for one instrument by ticker'), followed by a compact list of the record's contents. No filler, no redundancy with annotations or schema.

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

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

Given the tool has a single parameter with a documented example, a full output schema (so return format is already defined), and annotations covering safety and idempotency, the description provides everything an agent needs: the scope, the lookup method, case-insensitivity, and the set of fields. Nothing essential is missing.

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

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

Schema coverage is 100% for the single ticker parameter, so the baseline is 3. The description adds meaning beyond the schema by noting case-insensitivity and explicitly enumerating the fields included in the full record, which helps the agent understand what the result will contain. This adds value without being redundant.

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 clear verb-resource pair: 'Full record for one instrument by ticker' – it names the specific resource (instrument) and the access method (by ticker), with case-insensitivity noted. It clearly distinguishes itself from sibling tools that search or compare multiple assets, since this returns a full record for a single instrument.

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 implies usage: use this when you need the complete record for a single instrument identified by ticker. It doesn't explicitly name alternatives or exclusions, but the context is clear that this is the go-to for full details on one product, as opposed to comparison or search tools. No misleading 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, non-destructive and closed-world, so safety is covered. The description adds the net-yield definition (annual net rent / tokenized property value), which clarifies data semantics, but says nothing about rate limits, freshness, or auth needs. With annotations carrying the safety profile, a 3 is appropriate.

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

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

Two sentences, front-loaded with what the tool returns and followed by the usage condition. Dense but no wasted filler; only the parenthetical formula slows the read slightly.

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 all seven optional parameters are covered. The description supplies the scope and yield definition needed to use it correctly; only sibling routing is left implicit.

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 every one of the seven parameters is documented inline, including sort order defaults and the offset/nextOffset pagination pattern. The description adds no parameter meaning beyond this, 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 and resource: drilling into the RealT portfolio for individual tokenized US rental properties, and enumerates the returned attributes (yield, token price, rent, occupancy). It establishes the position in the hierarchy ('behind the REALT entry', 'within one issuer') but does not name a sibling it should be chosen over.

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 a clear triggering context: 'when someone asks which specific tokenized property to buy, or for the yield/price spread within one issuer.' This is real usage guidance, though it names no alternative tool and states no exclusions or prerequisites.

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 a safe, idempotent, non-destructive read, so the bar is lower. The description still adds real context: default tier, what imported rows do and do not carry, and that output is compact rather than full records. It stops short of describing pagination or result ordering.

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, zero filler, with the default-tier scoping and the sibling pointer front-loaded. Every sentence carries information an agent needs to route or invoke correctly.

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 detail isn't required; the description still flags compact records and points to get_product_details for the full record. Combined with a fully documented 7-parameter schema, nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, and the description largely restates the tier semantics already present in the tier parameter's schema text. It reinforces intent but adds little syntax or format meaning beyond the schema, so the 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 (search/filter) plus resource (TokenBank yield instruments) and distinguishes itself from get_product_details, which it explicitly names as the fuller-record alternative. The tier behavior is described up front so an agent can tell what corpus it queries.

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

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

Gives explicit when-to-use rules: curated tier for yield/minimum/risk questions, imported tier only for identity questions, and get_product_details for full records. The exclusions ('never for yield rankings') are rare and valuable routing guidance.

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