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

Annotations declare a non-read-only, non-destructive write, and the description adds exactly the context they cannot: free-plan cap of 50 addresses, a 1-credit cost, the no-op semantics for duplicates (existing label preserved), and that the full address book is returned. That is the mutation behavior an agent needs before spending credits.

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 short sentences, front-loaded with what gets saved, then duplicate behavior, then limits/cost, then return value. No filler and no redundant restatement of the 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?

Covers the mutation semantics, plan cap, credit cost, idempotency on duplicates, and the return value ('the full address book') despite there being no output schema. Nothing material an agent needs before calling is absent.

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 a single nested array parameter, so the baseline is 3; the description earns extra by noting that each entry takes an optional label and that the address must be a wallet on one of the four named chains, which the schema never says. It does not restate the 1-100 per-request bound, which lives in 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 and resource ('Save addresses ... to the address book') plus the supported chain families (EVM, Solana, Starknet, Tron) and the optional label. It also names the sibling octav_rename_address_book_entry for the related-but-different operation, so it is distinguishable 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?

Explains the already-exists case ('keeps its existing label') and routes the agent to octav_rename_address_book_entry for relabeling, plus states the 50-address free-plan ceiling. It does not explicitly say when to prefer this over creating a bundle or list, but the nearest alternative is covered.

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 this is a non-read-only, non-destructive, open-world mutation. The description adds genuinely new context beyond them: the address-book prerequisite, the fact that the updated bundle is returned, and a cost of 1 credit — billing/rate information the agent cannot get from structured fields.

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

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

Four short sentences with no filler, front-loaded with the action and followed by the precondition, return, and cost in priority order. Every sentence earns its place.

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

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

No output schema exists, and the description partially compensates by saying the updated bundle is returned. Combined with the precondition and cost note, an agent has enough to call this correctly; only the failure mode for an address not in the address book 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 coverage is 100%, so both parameters are documented in the schema already. The description only restates the address precondition and adds no format, ID convention, or validation detail; baseline 3 is appropriate when the schema carries the semantics.

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 ('Add one address to a bundle'), which is clearly distinct from sibling operations like octav_remove_bundle_address and octav_add_address_book_entries. It does not explicitly name a sibling alternative, so it sits just below the top mark.

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 concrete prerequisite: the address must already exist in the address book. It does not state when to use this versus removing/replacing bundle addresses or how to first add an address book entry, but the usage condition is clear enough to act on.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context about the payment mechanism ('Costs paid via HTTP 402 payment protocol') and the automatic payment requirement, which are not present in the annotations.

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

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

The description is only two sentences, front-loaded with the core function, and contains no redundant or filler content. Each sentence contributes essential information about purpose, audience, and payment behavior.

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 is simple with one well-documented parameter and strong annotations. The description covers purpose, usage context, and output summary, but it does not mention the alternative octav_get_portfolio for non-payment scenarios, leaving slight ambiguity for agents comparing siblings.

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 input schema already provides full coverage of the 'addresses' parameter, including accepted formats (EVM: 0x... or Solana base58) and limits (max 10 addresses). The description does not add parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool 'Get full portfolio' via x402 payment protocol and specifies the return content (wallet + DeFi positions). It distinguishes from the sibling octav_get_portfolio by noting it is intended for 'AI agents with automatic payment'.

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

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

The description provides clear usage context: 'For AI agents with automatic payment' and mentions that costs are paid via HTTP 402. However, it does not explicitly name alternatives or state when not to use this tool, falling short of the highest rating.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds valuable context about payment costs via HTTP 402, which is not covered by annotations, enhancing behavioral transparency.

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

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

The description is concise (three sentences) and front-loaded with the core action. Each sentence serves a purpose: defining the action, identifying the target user, and clarifying the output and cost mechanism.

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

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

For a simple read-only tool with a single well-described parameter and no output schema, the description covers the essential aspects: purpose, payment requirement, and return type. It could be more explicit about alternative tools but is otherwise 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?

The input schema fully describes the 'addresses' parameter, including format and limits. The description adds no additional parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action 'Get wallet holdings' and specifies the unique x402 payment protocol, distinguishing it from sibling tools like octav_get_wallet. It also explicitly mentions the output ('Returns wallet balances and values').

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

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

The description provides a clear usage context: 'For AI agents with automatic payment.' This indicates the intended audience but does not mention alternatives or exclusions (e.g., when to use a non-payment tool like octav_get_wallet).

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

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

Goes well beyond the annotations (readOnly=false, destructive=false, openWorld=true) by disclosing uniqueness rules, non-empty requirement, duplicate-set prohibition, default quotas of 5 bundles/10 addresses, that API-created bundles are private, and a 1-credit cost. This is exactly the operational context annotations cannot express.

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

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

Front-loaded with the action and the prerequisite, then a compact constraint list. Dense but every clause carries operational meaning; only slight cost is the staccato constraint run-on rather than grouped prose.

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 output schema exists, so ideally the description would hint at what a created bundle returns (id/name). Otherwise it covers inputs, constraints, limits, privacy, and cost thoroughly for a 2-parameter mutation.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'must already be in the address book' constraint. The description adds only the credit cost and privacy note, which are not parameter-level semantics. Baseline 3 is appropriate.

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

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

States a specific verb and resource (create a named bundle) plus its scope: addresses sourced from the address book. This clearly separates it from siblings like octav_add_bundle_address (adding to existing bundle) or octav_list_bundles.

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 the agent to octav_add_address_book_entries as the prerequisite step before calling this tool, and spells out the conditions under which the call will fail (non-unique name, empty bundle, duplicate address set, default limits). No inference required.

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 and openWorldHint=true, but the description adds genuinely new behavior: addresses survive deletion in the address book, the confirm precondition, and a cost of 1 credit. That is real value beyond the structured hints, though it omits whether other bundle metadata is lost.

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 terse sentences with zero filler, front-loading the action and the destruction-survival fact before the precondition and cost. Every sentence carries a distinct piece of 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 two-parameter destructive tool with no output schema, the description covers the mutation's blast radius, precondition, and cost. Only the failure behavior (e.g., what happens on confirm=false or invalid bundleId) 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% and both parameters are already documented, including confirm's "must be true" semantics. The description restates the confirm requirement and adds the credit cost, but contributes no new syntax or meaning for bundleId.

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 ("Delete a bundle") and immediately clarifies the side effect on contained addresses, which implicitly separates it from octav_remove_address_book_entry. It does not explicitly name a sibling alternative, so it stops short of full 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?

The description gives a precondition ("Requires confirm: true") but never says when to choose this over octav_remove_bundle_address or what the user-facing consequence of deleting versus emptying a bundle is. Usage is implied rather than guided.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds useful behavioral context: it mentions the cost ('Costs 1 credit') and the outcome ('Shows eligible airdrops with claim links'). It does not contradict 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 concise and front-loaded, with four short sentences each adding distinct information: purpose, output, constraint, and cost. There is minimal redundancy, and every sentence earns its place.

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

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

For a simple single-parameter tool with good annotations and no output schema, the description adequately covers what the tool does, the input requirement, the output/behavior (eligible airdrops and claim links), and cost. It is complete enough for an agent to use it correctly without needing additional context.

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

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

The schema already provides full coverage (100%) for the single parameter 'address' with a clear description ('Solana wallet address (base58 format)'). The description reinforces this with 'Solana addresses only' but does not add significant new meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb 'Check' and resource 'airdrop eligibility', and distinguishes it from sibling tools by focusing on airdrops specifically. It also specifies the input type (Solana address) and output (eligible airdrops with claim links).

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 clear context for when to use the tool: to check airdrop eligibility for a Solana address. It also includes an exclusion ('Solana addresses only'), which helps the agent avoid using it for non-Solana addresses. However, it does not explicitly mention alternatives or when not to use it compared to sibling tools.

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

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

Annotations already establish readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: pagination via cursor, end-of-pages semantics, and a 1-credit cost.

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

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

The description is three short sentences, front-loaded with the primary purpose, followed by pagination behavior and cost. Every sentence carries operational value with 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?

For a read-only retrieval tool with no output schema, the description covers purpose, pagination, and cost well. It does not describe the shape of returned approval records, but enough context is provided for an agent to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning for the cursor parameter by explaining that absent or null cursor indicates no more pages. It also reinforces the single-chain scope, though it does not add details for address or limit beyond the schema.

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

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

The description states a specific verb and resource: it gets ERC-20 token approvals/allowances for a wallet, scoped to spender contracts on one chain. This is precise enough for an agent to distinguish it from portfolio, token overview, and chain-listing siblings 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?

The description implies the tool is for inspecting a wallet's ERC-20 approvals on a single chain, but it gives no explicit when-to-use guidance, prerequisites, or comparison to alternatives such as token overview or portfolio tools. Usage is inferable from the resource wording but not directly 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, destructiveHint=false and openWorldHint=true, so the description's job is to add what the annotations cannot say: the credit cost ("Costs 1 credit") and the shape of the payload (name and addresses). That is genuinely useful non-structured context, though it omits error behavior for an invalid or foreign bundle id.

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 short sentences, front-loaded with the action and payload, then the id-discovery route, then the cost. Nothing is redundant and nothing could be cut 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 one-parameter read with no output schema, the description covers what is returned (name and addresses), how to obtain the id, and the credit cost. A minor gap remains around failure modes for unknown ids, but the tool is otherwise callable with confidence.

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?

There is a single required parameter with 100% schema coverage, so the schema already documents it; the description adds no format, sourcing, or validity detail beyond telling the agent where to get ids. 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?

Specific verb (get) + resource (one bundle by id) + scope (single bundle, not a list), plus a statement of what is included in the response (name and addresses). This clearly distinguishes it from octav_list_bundles and the bundle-mutation siblings.

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 octav_list_bundles to find bundle ids" explicitly routes the agent to the sibling that supplies the required identifier, which is the main precondition for calling this tool. It stops short of stating exclusions or prerequisites (e.g., auth/credits required), so it is clear context rather than full when/when-not guidance.

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

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

Annotations already establish that this is a read-only, non-destructive, open-world tool. The description adds useful behavioral details: results are paginated, the response indicates whether more pages exist, and the call is free with no credits required.

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 compact and front-loaded around what is listed, why the keys matter, and pagination/cost behavior. Every phrase adds useful information without 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?

For a simple read-only listing tool with no output schema, the description explains the returned content and pagination behavior sufficiently. It could say more about the exact response shape, but the essential context for correct invocation is present.

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 chain, page, and limit including defaults and bounds. The description does not add parameter-specific syntax or constraints beyond what the schema provides.

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: list DeFi protocols tracked by Octav on a given chain. It also explains that the returned keys are used by the protocol filter on octav_get_transactions, which separates this tool from generic transaction or chain-listing tools.

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

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

The description gives a clear use context by saying the protocol keys are used by the protocol filter on octav_get_transactions. It does not explicitly name when not to use this tool or contrast it with octav_get_contract_protocol, so it falls short of fully explicit alternative guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds useful behavioral context beyond that: the endpoint is free, requires no credits, and returns chain support flags for portfolio and transactions.

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

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

The description is two compact sentences with the core purpose front-loaded. Every clause adds useful information: output fields, downstream use of the chain key, and the free/no-credit behavior.

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, but the description enumerates the important return fields, including the chain key and support flags. Combined with annotations and an empty input schema, it gives the agent everything needed to call this tool confidently.

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?

This tool has zero parameters, so there is no input schema semantics to explain. The baseline for zero-parameter tools is 4, and the description appropriately avoids inventing parameter details.

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

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

The description uses a specific verb and resource: 'List every chain Octav supports.' It also names the returned fields (key, name, chain id, support flags), so an agent can immediately distinguish this discovery tool from all portfolio, transaction, and bundle siblings.

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 clear usage context by explaining that the returned key is used by chain filters in other tools, and notes the call is free. It does not explicitly state when not to use it or name alternatives, but no sibling appears to overlap with this purpose.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing credit cost (5 credits) and the refund policy when no protocol is found, plus the conditional return shape ({protocol} with chain vs {protocols} without). These are exactly the traits an agent needs before spending credits on an open-world lookup.

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 short sentences: purpose first, invocation context second, behavior/cost last. Every clause carries information a caller needs; nothing is padded.

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

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

There is no output schema, yet the description still specifies both possible return shapes and the billing outcome, so an agent can call it and interpret the result without further discovery. Nothing material is missing for a two-parameter read 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 real value by tying the optional chain parameter to a different response shape rather than just repeating 'omit to search every chain.' The contract parameter's accepted formats are left entirely to 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: 'Identify the DeFi protocol a contract address belongs to.' It also gives concrete call-site examples (spender from octav_get_approvals, transaction counterparty), which distinguishes it from the sibling octav_get_chain_protocols that enumerates protocols for a chain.

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?

Clear context for when to reach for it: after pulling approvals or transactions, to label an address. However, it never explicitly names octav_get_chain_protocols as the alternative for browsing protocols or says when not to use this tool, so the routing is implied rather than 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 and destructiveHint=false, and the description adds the behavioral detail 'FREE - no credits required', which is not captured by annotations. This provides useful cost-related context beyond the structured metadata.

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 only two short sentences with no filler. The key purpose is front-loaded, and the 'FREE' note adds valuable context without redundancy.

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

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

Given the tool has no parameters, no output schema, and simple read-only semantics, the description fully covers what an agent needs to know: what it checks and that it costs no credits. No additional context is necessary.

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

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

The tool has zero parameters, so the schema is trivially 100% covered. The description needs no parameter detail; the baseline of 4 applies as there are no parameters to explain.

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

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

The description uses a specific verb 'Check' plus the resource 'API credit balance, usage, and remaining credits', making the tool's purpose unambiguous. It clearly distinguishes itself from siblings since none of the sibling tools relate to credit balance.

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

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

The description provides clear context that this tool is for checking credit balance and is FREE (no credits required), implying safe usage. It does not explicitly mention alternatives, but no sibling tool serves the same function, so the guidance is adequate.

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

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

Annotations already declare readOnlyHint: true and destructiveHint: false, so the safety profile is known. The description adds useful context: 'Costs 1 credit per address,' which is a rate/pricing detail not present in annotations. It does not disclose other behaviors (e.g., response format), but the annotation coverage lowers the bar.

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

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

The description is three short sentences, front-loaded with the core purpose. Every sentence adds value: purpose, output content, and cost. No redundant or vague wording.

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

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

The description explains what the tool returns (holdings and values) and notes the credit cost, which is helpful since there is no output schema. It does not mention data availability limitations or chain specifics, but the schema already covers address formats. Overall, it is adequately complete for a relatively simple read-only 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 description coverage is 100%, with both 'date' and 'addresses' fully described in the input schema. The description does not add parameter-level detail beyond what the schema provides, so the baseline score 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 description clearly states the tool's function: 'Get portfolio snapshot for a specific date in the past.' It names the specific resource (portfolio snapshot) and the temporal scope, distinguishing it from siblings like octav_get_portfolio (current) and octav_get_nav.

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 clearly conveys when to use it (for past dates) and what it shows, but it does not explicitly name alternatives or state when not to use it. The context is clear enough for an agent to infer the historical use case.

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 provide readOnlyHint and destructiveHint, and the description adds useful context about credit cost per address, which goes beyond the schema and annotations.

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

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

Two short sentences, front-loaded purpose, no filler. Slightly redundant currency list already in schema, but overall compact.

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 output schema, so description should clarify return value; it doesn't. Also doesn't explicitly mention aggregate vs per-address NAV, though 'total net worth' implies aggregate. Lacks potential error handling details, but annotations cover safety.

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 has full coverage with descriptions and enum. The description attempts to add currency info but contradicts schema by listing ETH and BTC which are not in the enum, creating misleading parameter semantics.

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?

Clear verb 'Get' with resource 'total net worth (NAV)' and scope (currency). Distinguishes from siblings like get_portfolio and get_wallet by focusing on NAV valuation.

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?

Implied usage for obtaining NAV in a currency, but no explicit guidance on when to prefer this tool over sibling tools or any exclusions. No alternatives named.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only needs to add value beyond that. It discloses a credit cost ('Costs 1 credit') and describes the return contents ('active positions, values, and P&L'), which are useful behavioral details.

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

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

The description is two short sentences, front-loaded with the core purpose, and every sentence adds value (what is returned and the credit cost). No fluff or redundancy.

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

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

Given the tool's simplicity (one parameter, no output schema) and the presence of annotations, the description provides sufficient context: it states the resource, the output, and cost. Minor gaps like return format or pagination are not critical for this low-complexity tool, but a bit more detail could make it fully 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?

The sole parameter 'address' is fully documented in the schema with its format ('Ethereum wallet address (0x...)'). The description adds no additional semantic detail beyond referencing 'address,' so the schema bears the responsibility, resulting in a baseline score.

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

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

The description uses the specific verb 'Get' with a clear resource: 'Polymarket prediction market positions for address.' It further specifies the output ('active positions, values, and P&L'), making it distinct from sibling tools like octav_get_portfolio.

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 the tool is for Polymarket-specific positions but does not explicitly state when to use it over alternatives or provide exclusions. Context is clear for the intended use case, but no direct comparison to sibling tools 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 establish read-only, non-destructive, open-world behavior. The description adds meaningful operational context beyond annotations: it waits for a fresh sync by default and costs 1 credit per address, which is important for invocation planning.

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 short sentences, front-loaded with purpose and followed by return content, sync behavior, and cost. Every sentence carries useful information with no redundancy.

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

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

No output schema is present, so the description usefully summarizes return content as token balances, values, and protocol positions. Combined with schema coverage and annotations, it is nearly complete, though it could mention latency or stale-cache implications more explicitly.

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 addresses, waitForSync, and includeExplorerUrls. The description only restates the default sync behavior and per-address credit cost, without adding further parameter semantics; baseline 3 is appropriate.

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

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

States a specific verb and resource: get complete portfolio, including wallet holdings and DeFi protocol positions across 20+ blockchains. It is clearly more expansive than wallet or token-specific siblings, though it does not explicitly distinguish itself from close siblings like octav_agent_portfolio or octav_get_portfolio_at_block.

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 this is the comprehensive portfolio tool and notes cost and sync behavior, but it does not say when to use it instead of octav_get_wallet, octav_get_token_overview, octav_agent_portfolio, or octav_get_portfolio_at_block. Usage is reasonably implied but 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 cover the safety profile (readOnly, non-destructive, open world), so the description's contribution is the add-on entitlement requirement, the 1-credit cost, and the point-in-time semantics ('every balance and price as of that block'). That last point is behaviorally important because it tells the agent prices are historical, not current. It does not cover pagination or response shape, so not a 5.

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

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

Two sentences, no filler. The resource and scope come first, and the prerequisites/cost follow, so an agent can decide viability quickly.

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 does at least characterize the return as balances and prices at that block, and it discloses the add-on and credit constraints. It leaves the response structure and any missing-data behavior unstated, which is a modest gap for a point-in-time portfolio call.

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

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

Schema coverage is 100% and the schema already enumerates the three chains and the address format, so baseline is 3. The description adds genuine meaning beyond the schema by clarifying that block determines the valuation point for both balances and prices — an interpretation the bare 'Block number' description does not convey.

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

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

States a specific verb and resource (get a portfolio) plus the distinguishing scope: a single EVM address valued at a specific block, on one of three named chains. That scope cleanly separates it from the current-state octav_get_portfolio and the time-series octav_get_historical without needing to name them.

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 real gating context — 'Requires the Portfolio at Block add-on' and 'Costs 1 credit' — which tells an agent both the prerequisite and the cost of choosing this over a cheaper sibling. It stops short of explicitly contrasting with octav_get_portfolio or octav_get_historical, so the alternative-selection rule is implied rather than 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 mark this as read-only and non-destructive. The description adds that it returns per-chain sync state and last sync time, and clearly states the tool requires no credits, which is useful context beyond the schema/annotations. No contradiction.

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

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

Two short sentences deliver purpose and key detail without redundancy. The 'FREE' note is a distinctive benefit and not fluff.

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

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

With no output schema, the description partially covers return contents (chains synced, last sync time). Combined with the schema's clear parameter documentation and simple read-only nature, the description is sufficient, though it lacks explicit mention of address count limits (already in schema).

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 covers 100% of the one parameter with a description. The tool description adds no additional parameter semantics beyond the schema, so baseline 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 clearly states the tool checks synchronization status of addresses across all chains, distinguishing it from sibling tools like get_portfolio or get_transactions. It also specifies output (sync state and last sync time), making the purpose 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 implies this is used to check sync status, but does not explicitly specify when to prefer it over siblings like sync_transactions or get_transactions. It provides context (across chains, free) but no exclusion criteria.

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 and non-destructive behavior, lowering the burden. The description adds the credit cost per address and the aggregated data scope, which are useful behavioral context beyond what annotations provide.

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

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

Two concise sentences, front-loaded with the core purpose, followed by output summary and cost. No wasted words.

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

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

For a simple read-only tool with fully documented parameters, the description covers the output concept. However, it does not mention potential limitations or alternatives, leaving slight gaps given the number of sibling 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?

Schema coverage is 100% with clear parameter descriptions for addresses and date. The description does not add additional semantics 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?

The description clearly states the tool returns aggregated token distribution across all chains, including token values and percentage breakdown. The resource is specific, but it does not explicitly differentiate from sibling tools like octav_get_portfolio or octav_get_wallet.

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 tool's purpose implies when to use it, but there is no explicit guidance on when to choose it over sibling tools or any exclusions. The credit cost note is a practical caveat but not usage 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 cover the safety profile (readOnly=true, destructive=false, openWorld=true), and the description adds genuinely non-derivable facts: a 250-transaction per-request cap and a per-address credit cost. It omits whether stale data requires a preliminary sync or what the response shape looks like.

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, front-loaded with purpose and followed by capabilities then hard constraints (limit, cost). The filter enumeration partially restates the schema, but it is compact enough to aid scanning rather than bloat.

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 14-parameter read tool with full schema coverage, existing annotations, and no output schema, the description supplies the operational constraints an agent needs (rate/cost, page cap) and the filter surface. The remaining gap is workflow context — whether a sync step is required first — which keeps it from a 5.

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 every one of the 14 parameters is already documented in the schema. The description's enumeration of filter dimensions (chain, type, protocol, counterparty, search, NFT token ID, dates, spam/dust) maps onto those parameters without adding syntax, defaults, or cross-field guidance, which is the baseline-3 case.

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 ('Query transaction history') plus two capabilities ('filtering and pagination'), which clearly separates it from octav_sync_transactions, the write-side counterpart in the sibling list. It stops short of explicitly naming that sibling, so the differentiation is inferable 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?

Conveys useful operating context (max 250 per request, 1 credit per address) but never says when to use this versus octav_sync_transactions or octav_get_portfolio, nor any prerequisite such as whether history must be synced first. Usage is implied by the tool name and filters only.

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

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

Beyond the readOnly/openWorld annotations, it discloses three behaviors an agent can't infer: a Pro plan is required, each address costs 1 credit, and the call blocks on a fresh sync by default. Cost, entitlement, and latency are exactly the traits that drive tool selection and batching decisions.

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 short sentences, each carrying distinct information (input source, output shape, usage flag, cost/latency), front-loaded with the core purpose. Nothing is redundant with itself.

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 covers returns by deferring to octav_get_portfolio's shape, and it covers cost, entitlement, and sync behavior. It does not describe error/partial-failure behavior when one virtual address fails, which leaves a small gap for a batched-address call.

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 real semantics the schema lacks: cost scales per address ('1 credit per address'), which interacts meaningfully with the max-10 limit, and it frames addresses as coming from a specific sibling. The aggregated/waitForSync notes largely restate schema defaults, keeping it below 5.

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 + resource (get portfolios) scoped to virtual users, and it explicitly separates itself from siblings by pointing at octav_list_virtual_users for the input and octav_get_portfolio for the output shape. An agent can distinguish this from octav_get_portfolio without opening either schema.

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

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

Gives a clear precondition (obtain virtual:<id> addresses from octav_list_virtual_users) and a usage branch ('set aggregated for one combined portfolio'), plus the default wait-for-sync behavior. It stops short of naming an explicit when-not alternative (e.g. use octav_get_portfolio for real wallets), so 4 rather than 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 establish read-only and non-destructive behavior. The description adds valuable context: it returns token balances and values across chains, excludes DeFi, and costs 1 credit per address. This goes beyond the structured annotations, providing operational cost and scope details.

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

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

The description is two sentences, front-loaded with the primary purpose, and the second sentence adds cost context. No filler or redundant text; every word contributes.

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

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

For a tool with one parameter, good annotations, and no output schema, the description covers purpose, scope, return content, and cost. It does not detail the return structure (e.g., token symbols, chain identifiers), but that is acceptable given the absence of an output schema and the tool's relative 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?

Schema coverage is 100% for the single 'addresses' parameter, so the baseline is 3. The description adds a cost-per-address semantic ('Costs 1 credit per address'), which clarifies how the array parameter is consumed and incurrs fees. This goes beyond the schema's format description.

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

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

The description clearly states the tool's function: 'Get wallet holdings only (excludes DeFi protocols). Returns token balances and values across all chains.' The verb 'Get' is specific, the resource 'wallet holdings' is well-defined, and the exclusion of DeFi protocols distinguishes it from siblings like octav_get_portfolio.

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 when to use this tool by explicitly stating 'only (excludes DeFi protocols)', signaling that it should be used for wallet token balances when DeFi positions are not needed. However, it does not name alternative tools or provide explicit when-not-to-use conditions, so it falls short of the highest bar.

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 openWorldHint=true, so safety is covered. The description adds useful behavioral context beyond that: the 1-credit cost and a preview of the fields returned. It does not mention ordering, pagination, or size limits, which keeps it from a 5.

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

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

It is a single, front-loaded sentence that identifies the resource, clarifies scope ('the same list shown in Octav Pro'), lists the return fields, and notes the credit cost. Every clause carries information; there is 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?

For a parameterless read-only tool with full annotation coverage, the description is nearly complete: it explains the returned fields and the credit cost. The only minor gap is the absence of any note on result ordering, pagination, or maximum list size, which an agent might need for large address books.

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 and the baseline is 4. The description correctly does not waste words on parameter semantics.

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 ('List every address saved in the account address book') and even enumerates the returned fields (label, plan, expiry, paid flag). This clearly distinguishes it from sibling address-book mutations such as octav_rename_address_book_entry and octav_remove_address_book_entry.

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 it should call this when it needs the account's saved addresses. There is no explicit when-to-use guidance, no mention of alternatives, and no note on when not to call it (e.g., versus bundle tools or add-address tools).

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

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

Annotations already cover the readOnly/non-destructive/open-world profile, so the description's added value is the cost disclosure ("Costs 1 credit") and the shape of what comes back. That is useful, non-redundant behavioral context; pagination or bundle-count limits are not mentioned, keeping it from a 5.

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

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

Two sentences, zero filler: the definition and return shape come first, then the actionable next step and cost. 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 zero-parameter list tool with no output schema, the description supplies the returned fields, the concept definition, cost, and a chaining target. Nothing material is missing for correct invocation.

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 no parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly does not waste space on inputs and instead spends it on output shape and cost.

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 every bundle"), defines what a bundle is ("a named group of address book addresses"), and enumerates the returned fields (id, name, addresses). "Every" and the plural make it clearly distinct from the singular sibling octav_get_bundle without opening either schema.

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

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

Adds a concrete downstream usage hint: pass a bundle's addresses to octav_get_portfolio to see its holdings, which implies when to call this. However, it never states when to prefer the singular octav_get_bundle (when the id is already known) or clarifies its relationship to octav_list_address_book, so alternative selection is only implied.

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 (readOnlyHint=true, destructiveHint=false), yet the description adds two non-obvious operational facts the agent cannot get elsewhere: a Pro entitlement gate and a 1-credit cost. It also describes the shape of each returned entry (virtual:<id> address, type, label), which goes 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?

A single sentence that front-loads the action and resource, then adds the resource definition, output fields, and access/cost constraints without any redundant restatement of the tool name. 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?

With no input schema, no output schema, and read-only annotations, the remaining burden is access conditions and return shape — both covered (Pro requirement, credit cost, per-entry fields). Only minor gaps remain: no indication of ordering, pagination, or what an empty account returns.

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 for a parameterless tool applies. The description correctly implies the listing is account-scoped rather than parameterized.

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 the virtual users on the account') and defines what a virtual user is (balance-tracking or CEX-linked accounts in Octav Pro). It does not explicitly distinguish itself from the closest sibling, octav_get_virtual_users_portfolio, but the resource definition makes the purpose 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 'Requires Pro' note implies a precondition but gives no alternative for non-Pro accounts, and there is no explicit guidance on when to use this versus octav_get_virtual_users_portfolio (which returns holdings for the same objects). Usage is inferable but not 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 flag destructiveHint=true, and the description adds value beyond them: the removal is permanent, the entry type is restricted on paid/owner-authorized entries, and each call costs 1 credit. The credit cost and the API-vs-Pro restriction are behavior facts an agent cannot get from structured fields.

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

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

Three compact sentences, front-loaded with the action, then the eligibility restriction, then the confirm and credit-cost constraints. Nothing is 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 destructive two-parameter tool with full schema coverage and no output schema, the description covers eligibility, confirmation, and cost. Only minor gaps remain, such as what happens to entries with dependent snapshots or bundles.

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

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

Schema coverage is 100% and the schema already documents both 'address' and the confirm-must-be-true boolean. The description repeats the confirm requirement without adding format or validation detail, so it does not meaningfully exceed 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 and resource ('Remove an address from the address book'), which cleanly separates it from the sibling rename tool and from the bundle-address tools that operate on a different resource.

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-you-cannot-use-it guidance: paid-plan entries or owner-authorized entries must be handled in Octav Pro instead of the API. It does not name a sibling as an alternative, but the exclusion condition is concrete enough to prevent a wrong call.

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false, openWorldHint=true), it discloses the credit cost, the confirm=true gate, the return payload, and the non-obvious invariant that a bundle can never be emptied. It does not detail whether removal is reversible beyond the 'stays in address book' note or what happens on a failed confirm — a small 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?

Four short clauses, each carrying a distinct decision-relevant fact — scope, invariant, precondition, return, cost — with the identity-statement first. 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?

For a 3-parameter mutation with no output schema, the description covers the destructive side effect, the precondition, the cost, and the response shape ('updated bundle'). Nothing an agent needs to call it safely 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 all three parameters are already documented. The description only echoes the confirm: true requirement and adds no meaning about bundleId or address formats 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 precise verb and resource ('remove one address from a bundle') plus a key scoping fact — the address remains in the address book — which separates it from octav_remove_address_book_entry. An agent can distinguish it from octav_delete_bundle and octav_add_bundle_address without reading 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?

Gives an explicit boundary condition and names the alternative action: a bundle cannot be emptied, so the last address requires deleting the bundle instead. It also pre-empts confusion with address-book removal by stating the address survives.

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 and openWorldHint=true, so the replacement semantics are partly pre-signalled; the description reinforces this by saying the current label is replaced. It adds genuinely new operational context the annotations do not carry: the confirm:true requirement and the 1-credit cost. It stops short of describing failure behavior for unknown addresses.

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 short sentences, front-loaded with the core action, followed by the edge case and the two operational requirements. Nothing is wasted and no sentence is redundant.

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

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

For a simple three-parameter mutation with no output schema, the description covers the action, edge case, confirmation gate, and cost. The only real gap is behavior on a missing or invalid address, plus any indication of what a successful response contains.

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 documents the empty-string-clears behavior and the confirm requirement. The description restates these rather than adding syntax, format, or constraint details 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 and resource: changing the label on an address already in the address book, and explicitly notes it replaces the current one. This clearly distinguishes it from octav_add_address_book_entries and octav_remove_address_book_entry without opening either schema.

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

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

The phrase 'already in the address book' implicitly scopes usage to existing entries and rules out the add tool. However, no sibling is named explicitly and there is no statement about what to do if the address does not exist.

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 and openWorldHint=true, so the mutation risk is covered structurally. The description adds genuinely new facts: case-sensitive name uniqueness and a 1-credit cost, which an agent cannot infer from annotations or schema. It does not say what happens when the name collides or whether the credit is spent on failure.

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 short sentences, zero filler, with the destructive effect front-loaded before the constraints and cost. Every sentence carries an independent fact.

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 3-param destructive mutation with full annotation and schema coverage and no output schema, the description supplies the two hidden costs (uniqueness, credits) an agent needs to call it safely. Only the failure mode on duplicate names is left 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 coverage is 100% and the field descriptions already explain name length and the confirm semantics. The description adds the uniqueness rule (case-sensitive), which is a real constraint not expressible in the schema, but adds nothing for bundleId.

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 ('Rename a bundle') plus the exact effect ('replacing its current name'). Sibling tools split cleanly into bundle vs address-book variants, and the resource noun here makes the distinction immediate.

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 prerequisites ('Requires confirm: true', 'Costs 1 credit') give an agent operational conditions for invoking it. However, there is no guidance on when to rename vs create_bundle/delete_bundle, nor any exclusion or alternative path.

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 key behavioral context beyond annotations: 'Costs 1200 credits' and 'automatic' imply ongoing side effects and cost. This is valuable given the annotations only indicate non-read-only and open-world hints. It does not contradict 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 extremely concise, using four short sentences that each convey essential information: purpose, benefit, cost, and parameter expectation. No filler or redundant phrasing beyond what schema requires.

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

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

For a simple subscription tool with only two parameters, the description covers the main points: what it does, why use it, cost, and parameter types. It lacks details about the return value or how to cancel, but given the absence of an output schema, the description is reasonably complete for 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 schema already documents both parameters with descriptions (100% coverage). The description's 'addresses with optional descriptions' merely restates the schema without adding deeper meaning (e.g., formats, constraints, or relationships). Baseline 3 is appropriate.

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

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

The description clearly states the action: 'Subscribe to automatic portfolio snapshots.' It identifies the resource (snapshots) and the purpose (historical tracking). This distinguishes it from sibling tools, which are all get_ or sync_ operations.

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

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

The description provides clear context for when to use this tool: 'Enables historical tracking.' This implies the tool is for setting up ongoing snapshots. However, it does not explicitly contrast with octav_get_historical or other alternatives, nor does it state 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 indicate write/non-destructive behavior, and the description adds important context: it costs 1 credit per address and forces indexing. This goes beyond what annotations provide, disclosing a rate-limiting cost and the tool's triggering nature, which is valuable for an agent to anticipate side effects.

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

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

The description is two sentences, front-loaded with the core purpose, and includes essential behavioral and cost information. There is no redundancy or filler; every word contributes to understanding.

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

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

For a simple trigger tool, the description covers what it does, when it matters, and its cost. It does not explain return values or error behavior, but since there is no output schema and the tool likely returns a status, this is a minor gap. Overall, it is adequately complete for 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 input schema describes the 'addresses' parameter fully (array of wallet addresses, max 10). The description does not add further parameter-level detail; the cost per address is a behavioral note rather than parameter semantics. Since schema coverage is 100%, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: manually triggering transaction synchronization for addresses and forcing immediate indexing of latest transactions. The verb 'trigger' and resource 'transaction synchronization' are specific and distinguish it from sibling read-only tools like octav_get_transactions.

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 when to use it—when you want to force an immediate sync rather than relying on automatic updates—but does not explicitly contrast it with alternatives or state when not to use it. The 'manually' and 'Forces immediate' phrasing provides context but no exclusionary guidance.

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