YieldCave

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 bar is lower. The description still adds real behavioral context: the computation is simple-interest, it compares against the highest-yielding liquid tokenized treasury, it returns arithmetic and assumptions only, and it gives no recommendation.

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 computation stated first and the output disclaimer second. Every clause carries information an agent needs.

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 4-parameter computational read tool with no output schema and full annotation coverage, the description is sufficient: it explains the inputs' meaning, the method, and the character of the result. It could say slightly more about the returned arithmetic structure, but nothing essential to 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 coverage is 100% with defaults documented for all four parameters, so the baseline is 3. The description reinforces currentApyPercent and horizon and hints at the liquidity floor via 'highest-yielding liquid', but adds no format or default detail beyond the schema, and never mentions amountUsd.

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 and computation: 'computes the simple-interest difference versus the highest-yielding liquid tokenized treasury over a horizon.' That clearly separates it from listing siblings like list_rwa_yields or stablecoin_yield_summary, which enumerate data rather than compute a comparison.

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

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

It gives a concrete trigger scenario ('an APY the user currently earns, e.g. a bank savings rate') and a scope exclusion ('does not recommend'), which tells the agent when the tool is appropriate. It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it is clear context without routing.

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 readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: hourly evaluation after data refresh, the 24-hour rate limit, webhook delivery semantics, and the return of an alert id for later deletion. It does not mention authentication or error behavior, but the added context is substantial.

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 denser than a single sentence but each clause carries needed information: cadence, delivery, rate limit, universe semantics, return value. It is front-loaded with the primary action and remains free of filler, though the universe explanation is slightly buried at the end.

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 mutation tool with no output schema, the description covers creation behavior, delivery, rate limits, and return value adequately. It leaves out authentication requirements or error conditions, but given annotations cover the safety profile and the schema covers most parameters, it is largely complete for an agent to invoke 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 88%, so the schema already documents most parameters. The description still adds meaning for the universe parameter ("rwa" for tokenized treasuries default, "stablecoin" for pools with at least $10M TVL) and the symbol omission behavior (omit for all major stablecoins), which goes beyond the schema's brief field descriptions. It compensates for some gaps in the low-coverage 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 states a specific verb and resource ("Creates a rule") and goes further to specify the evaluation cadence ("checked every hour after the data refresh") and the delivery mechanism (POSTs a JSON payload to an HTTPS webhook). It clearly distinguishes itself from siblings like list_alerts or delete_alert by describing alert creation and even names the delete counterpart.

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 explains the operational context: how often the rule is checked, the rate limit ("at most once per 24 hours per rule"), and the webhook targets (Slack, Discord, Zapier, custom server). It implies when to use it (crossing a threshold on deployments) but does not explicitly state when NOT to use it or list alternatives like list_alerts for viewing existing alerts.

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 genuinely valuable traits beyond the annotations: the key is shown only once (a critical one-shot disclosure the annotations don't convey), the free-tier quotas, the one-key-per-email uniqueness constraint, and the exact auth mechanism (x-api-key header or Authorization: Bearer). This goes well past the readOnly/destructive/idempotent hints.

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 tight sentences, front-loaded with purpose then the operational details an agent must retain (shown once, header format, uniqueness). No filler or repetition.

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?

There is no output schema, so the description carries the return-value burden and does so by warning that the key is displayed only once. Combined with quotas, auth header usage, and the uniqueness rule, an agent has everything needed to call this and persist the result 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?

With a single param and 100% schema coverage, baseline is 3. The description adds meaning by clarifying that the email is the key's owner and enforcing 'one key per email', which qualifies the schema's vaguer 'Where to reach you about the key' framing.

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 a free YieldCave API key') and immediately scopes it with concrete limits (300 calls/day, 3 alerts, 7 days of history) tied to an email. It is unmistakably distinct from siblings like upgrade and manage_subscription, which are about billing/subscription state rather than issuing a key.

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 rather than stated: the free-tier limits and the 'one key per email' rule suggest when this is appropriate, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative (e.g., upgrade for higher limits). Adequate but leaves routing 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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is fully covered by structured fields. The description adds nothing beyond them: no note about irreversibility, behavior when the id does not exist, or permission requirements. With annotations carrying the full burden, one sentence of extra context is expected.

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 words, front-loaded, with zero padding, which is structurally fine. But the brevity comes from under-specification rather than efficient communication, so it does not earn a high score.

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 mutation with no output schema, the annotations cover destructiveness and idempotency, which is most of what an agent needs. Missing are error behavior on unknown ids and any hint that the id comes from list_alerts, leaving it only minimally complete.

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

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

Schema description coverage is 0%, and the schema already types 'id' as a required UUID. The phrase 'by id' restates the single parameter without adding format, source, or lookup guidance, so it does not compensate for the coverage gap.

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 ('Deletes an alert'), so the operation is unambiguous. However, it does nothing to distinguish itself from its siblings create_alert and list_alerts beyond the verb, so sibling differentiation comes only from the tool name.

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 no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_alerts for discovering the id first. Usage is only inferable from the tool name.

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 covered. The description adds return-shape context that the annotations cannot: it discloses that the result aggregates every chain deployment plus total TVL and a curated description. It says nothing about behavior for an unknown or ambiguous symbol, 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?

A single sentence that front-loads the verb and scope and then lists the returned fields; every clause earns its place and there is no 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?

For a one-parameter read tool with full annotation coverage, the description is nearly complete - it covers scope, key parameter semantics and return contents in the absence of an output schema. Only the failure mode for an unrecognized symbol 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?

Schema description coverage is 100% and the schema already defines 'symbol' with an example, so the baseline is 3. The description adds matching examples (BUIDL, USDY, OUSG) that confirm the expected symbol vocabulary, but no format or case-sensitivity rules.

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 gives a specific verb and resource ('Returns every deployment of one tokenized asset symbol ... across chains') plus the concrete payload (TVL, curated description), so the agent knows exactly what it gets. It stops short of naming any sibling (e.g. get_tokenized_equity or list_rwa_yields) to confirm this is the single-symbol, cross-chain lookup rather than a list endpoint.

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

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

There is no when-to-use or when-not-to-use guidance and no alternative is named, even though siblings such as get_tokenized_equity, list_rwa_yields and rwa_issuer_terms occupy adjacent territory. The agent must infer from the name alone that this is the single-symbol lookup.

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 a closed-world non-destructive read, so the safety profile is covered. The description adds genuine context beyond that: the exact result payload and the Pro-tier gating on the premium/discount field, which is a behavioral constraint the annotations do not 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?

One front-loaded sentence naming the resource and scope first, then the payload contents. Nothing is redundant and the parenthetical Pro caveat is the only qualifier needed.

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 and a single required parameter, the description covers what matters by enumerating returned fields and the tier-gated field. It stops short of noting result limits, whether every issuer is guaranteed, or pagination, which leaves a small gap for a cross-issuer aggregation 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?

Schema coverage is 100% and the single parameter is fully documented (ticker, e.g. 'NVDA'). The description's 'e.g. TSLA' restates the same idea without adding format, exchange, or normalization rules, so the schema carries the load — baseline 3.

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 with clear scope: all tokenized wrappers of ONE underlying stock across issuers, listing exactly what is returned (market caps, volumes, chains, most liquid wrapper, premium/discount). The 'one underlying stock' scoping cleanly separates it from list_tokenized_equities and tokenized_equity_summary, which an agent can distinguish without opening any 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?

Usage is implied: call it when you have an underlying ticker and want every wrapper for it. The '(on Pro)' note hints at a tier prerequisite, which is useful, but no alternative sibling is named and no explicit when-not condition is given.

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, and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely new behavioral context beyond that: results are redacted to webhook hosts and never expose full URLs, which tells the agent what it will and will not receive.

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 sentence with zero filler, front-loading the resource and following immediately with the output-scoping caveat. Nothing could be removed without losing 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?

For a zero-parameter, read-only list tool with no output schema, the description covers what is listed and how the output is redacted, which is the key thing an agent needs. It omits pagination/result-size behavior, a minor gap given the tool's simplicity.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the parenthetical clarifies output content rather than parameter meaning, but no parameter gap exists.

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 ('Lists') and resource ('alert rules') with a scope qualifier ('active'), so an agent knows exactly what it retrieves. It does not explicitly contrast itself with the sibling create_alert/delete_alert, but the read/list framing is 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?

The description offers no when-to-use guidance, no mention of alternatives such as create_alert or delete_alert, and no prerequisites or exclusions. The purpose sentence implies a listing scenario but nothing routes the agent between this and its siblings.

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 openWorldHint=false, so the safe-read profile is covered. The description usefully adds the public DefiLlama data source and a non-advice disclaimer, but says nothing about data freshness, rate limits, or response shape beyond the APY/TVL mention.

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 tight sentences, front-loaded with what is returned and where the data comes from, followed by filtering and the disclaimer. No 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?

There is no output schema, so the description must hint at return contents, which it does by naming APY and TVL alongside chain/kinds. That is enough for an agent to call it correctly; only pagination/freshness details are absent, which are minor for a read-only list.

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%, including enum semantics for kind, defaults for limit, minTvlUsd, and sortBy, so the schema carries the parameter burden. The description only gestures at "filter by chain or kind" and adds no syntax or units beyond what the schema states, 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 (Lists) and resource (tokenized real-world asset deployments), with concrete examples (treasuries, credit, funds) and named output fields (APY, TVL). This clearly separates it from siblings like list_stablecoin_yields and list_tokenized_equities.

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?

"Filter by chain or kind" gives implied usage, and the DefiLlama provenance plus "information only, not advice" frames intent. However, it never says when to prefer this list tool over siblings such as get_rwa_asset for a single asset or rwa_market_summary for aggregates, so routing 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 already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the bar is lower; the description still adds real substance: the data source, the default TVL floor and sort order, and the exclusion of tokenized treasuries. It does not discuss freshness/latency or result caps beyond the default.

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 but front-loaded: the resource and scope come first, then row contents, then defaults, then the disclaimer. Clause-heavy sentences carry real information without padding, though the parenthetical structure is slightly hard to parse on first read.

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 compensates by enumerating what each row carries (category group, base vs reward APY, 30-day mean APY, TVL) plus defaults and exclusions. An agent has everything needed to call and interpret this read-only list 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?

Schema coverage is 100% so the baseline is 3, but the description adds meaning beyond the schema by explaining that 'group' corresponds to the protocol category groups (lending, vault, credit, basis) and by restating the default $10M TVL floor and highest-APY-first ordering with rationale. That is more than the raw field descriptions provide.

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/scope: current stablecoin yield venues across named stablecoins, limited to single-asset pools on lending markets and vaults. It explicitly distinguishes itself from the tokenized-treasury tools, which is exactly the sibling overlap an agent needs resolved.

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 context (spot yields, DefiLlama sourced) and an exclusion ('excludes tokenized treasuries, which have their own tools'), implicitly routing the agent to those sibling tools. It never names the alternative tool explicitly the way a 5 would, but the routing signal is unambiguous.

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 value beyond that by disclosing the returned field set and the tier gating ('on Pro') of premium/discount data, plus an 'information only, not advice' disclaimer. It stops short of describing pagination or default-result 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 resource and issuer roster are front-loaded, followed by the returned fields, filters, and a one-clause disclaimer. It is dense but every element is on-topic; the long issuer enumeration is the only mild 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 no output schema, the description usefully compensates by naming the returned fields. For a 7-parameter, zero-required list tool it covers what the agent needs to invoke it, though it never clarifies default behavior with no filters applied or how results are ordered/paged.

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 86%, so the schema already documents chain, limit, issuer, sortBy, underlying, and minMarketCapUsd. The description's filter list largely restates those parameters (including duplicating the kind enum), adding only the notion that premium reflects distance from the underlying quote.

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 (list tokenized equities) and enumerates the concrete data returned: token price, market cap, 24h volume, underlying ticker, chains, and premium/discount. This clearly separates it from singular siblings like get_tokenized_equity and aggregate siblings like tokenized_equity_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?

It says how to filter ('Filter by issuer, kind (stock, pre-ipo, etf), underlying or chain') but never says when to pick this over get_tokenized_equity or tokenized_equity_summary, nor whether filters are required or optional. Usage is implied by the filter list, not explicitly routed.

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 disclose openWorldHint=true, idempotentHint=false, and destructiveHint=false, and the description is consistent with them. It adds genuine context beyond the annotations: the tool returns a link rather than performing the mutation itself, so the actual cancel/update happens in Stripe's portal, and it requires a subscription-backed API key. It stops short of noting link expiry or any rate/usage 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?

Two tight sentences with the capability and the three supported actions front-loaded, followed by the precondition. Every sentence earns its place; nothing is redundant with 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?

For a zero-parameter tool with no output schema, the description covers everything needed: what it returns (a Stripe Billing Portal link), what can be done with it, and the auth prerequisite. No material 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 takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a parameterless invocation and adds the auth precondition, which is the only input-relevant information an agent needs.

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 concrete verb+resource: it returns a Stripe Billing Portal link scoped to payment details, invoices, and cancellation of the Pro subscription. That is far more specific than the name/title, and it implicitly frames the scope as 'manage an existing subscription'. It does not explicitly name the sibling 'upgrade', so differentiation from that tool is left to inference.

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 clear context for when to call it (to update payment details, see invoices, or cancel Pro) and states a prerequisite — an API key with a subscription. There is no explicit when-not condition or named alternative, which keeps it out of 5 territory.

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 covered. The description adds the returned content set, which is useful but not behavior beyond the structured data (no quota/rate-limit consequences, no caching or freshness notes).

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 with no filler; the list of returned fields earns its space given there is no output schema. Slightly list-heavy but well within acceptable size.

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 and no parameters, the description compensates by enumerating exactly what the caller receives (plan, daily calls, remaining allowance, alert allowance, depth limits, plan contents). Complete for a simple self-status read, missing only a note on whether the call consumes quota.

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?

Zero parameters, so there is no argument semantics to explain; baseline for a no-param tool is 4. The description correctly reflects that the scope ('the caller') is implicit and requires no input.

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 ('Shows') and resource ('the caller's plan, calls used today, remaining allowance...') and enumerates the exact contents returned. An agent can distinguish this from mutation siblings like upgrade or manage_subscription. It stops short of explicitly naming those siblings, so a 4 rather than 5.

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?

No when-to-use guidance and no relationship to alternatives. It is not stated when an agent should call my_usage versus upgrade or manage_subscription, nor whether it is free to call. Usage must be inferred from the name alone.

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). The description adds useful behavioral context beyond that: what is compared, ordering (biggest movers first), and inclusion of new/vanished deployments. It does not cover auth or pagination, but for a read-only tool this is a solid addition.

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 compact sentences with the core comparison front-loaded and no wasted words. The second sentence about universe is a fragment and kind/limit are omitted, but the overall size is appropriate and efficient.

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 usefully explains the return shape (APY/TVL changes, movers, new/vanished deployments) and scope via universe. Annotations cover safety and the schema covers all parameters, so the main remaining gap is the unexplained kind parameter, which the schema itself documents.

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 days, kind, limit, and universe. The description restates only the universe default and N-day comparison default, adding little beyond the schema. Baseline 3 is appropriate when the schema carries parameter documentation.

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: compares the latest market against an N-day snapshot, returning APY/TVL changes, top movers, and new/vanished deployments. This delta-oriented behavior clearly separates it from siblings like rwa_market_summary (current state) and rwa_history (historical series).

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 default values and implies usage (see what changed over N days), but never explicitly says when to choose this over rwa_market_summary, rwa_history, or the yield list tools. No exclusions or alternative routing are provided.

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-destructive profile, and the description goes further by disclosing plan-tier behavior (Free/anonymous see 7 days, Pro sees full history), the default window, and that the payload includes first-to-last change. This kind of access/quota disclosure is genuine value beyond the annotations, though it omits any mention of response granularity or 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 core purpose is front-loaded in the opening clause, with qualifiers (chain, N days, plan limits, universe) stacked after. Dense with parentheticals but no wasted sentences; slightly harder to scan than an ideal two-liner.

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-shape burden and does say the payload includes the first-to-last change, plus documents plan-scoped history depth. Complete enough to call correctly; only the exact snapshot record shape is left unstated.

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 nudges above it by clarifying the semantic meaning of the universe values ('rwa' = tokenized assets default, 'stablecoin' = stablecoin pools) and restating the default 30-day window, which the bare enum 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+resource: daily snapshots of TVL and TVL-weighted APY for a single symbol, scoped by chain and time window. An agent can distinguish it from summary-style siblings like rwa_market_summary, but it never explicitly contrasts itself with the closest lookalikes (rwa_changes, list_rwa_yields), so it stops just short of full sibling differentiation.

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

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

Usage is implied by the description's scope ('one symbol', 'last N days'), but there is no explicit when-to-use or when-to-prefer-an-alternative statement, and no routing to rwa_changes or list_rwa_yields. Adequate but leaves the agent to infer selection.

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 read-only, idempotent, non-destructive, closed-world behavior, so the bar is low. The description still adds real value beyond them: tier gating (summary on Free; Pro adds backing, domicile, redemption, fees, yield mechanics and source URLs) and the crucial 'Null means not stated by the source' semantic.

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 dense paragraph with no wasted clauses; the return-shape information is front-loaded after the purpose statement. Slightly cramped, but 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 output schema, the description handles the return burden by enumerating the fields available at each tier and the null convention. Missing only things like whether a null/missing symbol errors or whether results are cached.

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 an example, so the baseline is 3. The description goes further by naming the supported symbols (BUIDL, USYC, USDY, OUSG, USTB, TBILL, STBT, BENJI), which tells the agent the valid input domain in a way the bare schema does not.

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: hand-curated issuer terms for a tokenized treasury token, and implicitly distinguishes itself from get_rwa_asset / list_rwa_yields by scoping to issuer-level terms. The coverage list of tickers makes the domain concrete.

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 — call it with a symbol to get that token's curated terms — but there is no explicit when-to-use vs. siblings like get_rwa_asset or compare_yield_to_tokenized_treasuries, and no stated 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that by enumerating the aggregate fields returned, which is the main behavioral question for a summary tool with no 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?

A single sentence, front-loaded with the scope (tokenized treasury market) followed by the returned metrics. No filler and nothing to trim.

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 parameterless read-only summary with no output schema, listing the returned fields is what the agent needs. The only residual gap is the boundary with sibling summaries — 'other tokenized real-world assets' could overlap with the separately exposed tokenized equity summary, which is left unresolved.

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 to document and no ambiguity for the caller. Baseline 4 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 the resource (tokenized treasury market) and enumerates exactly what the tool returns: distinct tokens, total TVL, median APY, top tokens by TVL, plus other tokenized RWA totals. That is enough to distinguish it from list-style siblings such as list_rwa_yields, though it never names a sibling 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?

Usage is only implied: an agent can infer this is the aggregate/summary entry point versus the list_* detail tools. There is no explicit when-to-use or when-not-to-use statement, and no guidance on how it relates to tokenized_equity_summary or stablecoin_yield_summary.

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 the default TVL floor and outlines the shape of the aggregate result, but that floor is the same value already exposed as the minTvlUsd default in the schema, so genuinely new behavioral context is thin.

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 return contents, and no filler. The semicolon-delimited list is dense but each clause maps to a distinct output element, so 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?

There is no output schema, so the description carries the burden of describing results, and it does so thoroughly by enumerating the per-stablecoin, per-category, and comparison fields. Combined with the documented default filter, an agent has what it needs, though it lacks any note on freshness or ordering of the ranking.

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 one parameter at 100% schema coverage, the baseline is 3. The description restates the $10M default but adds no format, units, or effect detail beyond what the schema property already documents.

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 the resource (stablecoin yield market) and enumerates the exact aggregates returned: venues, TVL, median APY, best venue, best collateralized-lending venue, category totals, and the treasury comparison. This is specific enough to distinguish an aggregate summary from a raw pool listing, but it never names the sibling list_stablecoin_yields that an agent might otherwise 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?

No statement of when to use this summary versus list_stablecoin_yields or compare_yield_to_tokenized_treasuries, and no exclusions. The only selection hint is the implicit $10M default filter, which is a behavior rather than 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, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds genuinely new behavioral context on top of that: the response content varies by subscription tier, with certain metrics and a wider top-N list appearing only on Pro. That plan-dependent variability is exactly the kind of thing annotations cannot express. It stops short of 5 because it says nothing about rate limits, caching, or freshness of the 24h figures.

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?

It is a single sentence with the head noun 'Totals' front-loaded, and each semicolon-delimited clause adds a distinct output group rather than padding. The density is high but the clause-per-metric structure is slightly hard to parse at a glance compared with a short bulleted list.

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 input schema properties and no output schema, the description bears the full burden of explaining what comes back, and it does so metric by metric, including the tier-dependent differences. Minor gaps remain: terms like 'kind', 'underlying quote', and 'median absolute premium' are used without definition, so an agent must infer them.

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 the schema carries no parameter semantics to miss and the baseline of 4 applies. The description correctly does not invent parameters, and instead spends its words on return content.

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 (tokenized equities) and enumerates exactly what the tool aggregates: token count, market cap, 24h volume, issuer/kind breakdowns, top underlyings, and premium statistics. That enumeration alone separates it from siblings like list_tokenized_equities and get_tokenized_equity, which return individual assets rather than computed totals.

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: this is the aggregate-overview call, contrasted implicitly with the per-asset list/get tools. It also discloses useful tier gating (top 5 on Free, top 10 on Pro; premium metrics Pro-only), which tells the agent what it will actually receive. However, it never states when to prefer this over list_tokenized_equities or rwa_market_summary, so the guidance remains inferential.

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 openWorld=true, non-idempotent, non-destructive, so the description doesn't need to re-state safety. It does add real behavioral context: the call returns a checkout link rather than performing a charge, and it requires an API key. It stops short of saying whether repeated calls create multiple checkout sessions, which matters given idempotentHint=false.

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: the return value comes first, then pricing and plan contents, then the auth requirement. The parenthetical feature list is dense but earns its place by telling the agent what the agent is selling.

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?

No parameters and no output schema, so the description only needs to cover what comes back and what's required — both are stated. Missing only whether the checkout link is single-use or whether the upgrade takes effect immediately.

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 baseline the schema carries no parameter semantics to explain and the description is not required to compensate. The plan/pricing detail is informational rather than parameter-related.

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 concrete verb+resource: returns a checkout link for the Pro plan, with pricing and plan contents spelled out. It does not differentiate itself from the related sibling manage_subscription, so it stops short of a 5.

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 intent (upgrade to Pro) is implied by the name and the pricing detail, and it notes the API-key prerequisite. It never says when to use this instead of manage_subscription or create_api_key, so usage 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.