cortexcloud

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

With no annotations, the description carries the full behavioral burden. It does disclose genuinely useful behavior beyond the schema: the Alchemy backend, the $0.004 USDC per-address cost model, and the 1-20 batch size. It omits read-only confirmation, any auth/permission requirement, rate limits, partial-failure behavior when some addresses are invalid, and return shape, leaving meaningful gaps.

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

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

Two tight sentences, zero filler. The core capability is front-loaded and the cost/size constraints follow immediately, so an agent can extract the essentials at a glance.

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 two-parameter read tool with no output schema, the description covers purpose, provider, cost, and bounds, which is close to sufficient. The remaining gap is that it does not describe the return payload despite no output schema existing, and chain behavior/default is left entirely to the 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 coverage is 50%: the chain parameter is documented in the schema with its enum-like value list, while addresses has no schema description. The description compensates partially by clarifying that addresses are ERC-20 balance lookups batched together and priced individually, which adds meaning beyond the raw array type. It says nothing about the chain parameter, so it does not fully offset the coverage gap.

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

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

The description states a specific verb and resource ('Batch ERC-20 balances for many addresses in one call') and names the data provider (Alchemy). The 'many addresses in one call' phrasing implicitly separates it from the single-address sibling cortex_token_balances, but it never names that sibling, so the differentiation is inferential rather than explicit.

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

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

It conveys the usage context (multi-address batching) and the 1-20 address envelope, plus per-lookup pricing that an agent could weigh in a cost/volume decision. However, it gives no explicit when-not guidance and never routes the agent to cortex_token_balances for a single address or to cortex_aggregate_prices for valuation.

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?

With no annotations, the description carries the full burden, and it does disclose two real behavioral traits: per-address pricing ($0.004 USDC) and a 1-20 address bound. It omits the read-only nature, pagination behavior (despite a page_size param), and the return shape, which is a meaningful gap for a paid batch tool.

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

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

Two tight sentences with the core capability front-loaded and cost/limit constraints in the second. No filler or redundancy.

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

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

For a 3-parameter tool with no annotations and no output schema, the description covers cost and batch limits but leaves pagination, chain behavior, and return contents unexplained. Adequate but short of what an agent needs to invoke it 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?

Schema coverage is only 33% — chain is documented, addresses and page_size are not. The description partially compensates by restating the 1-20 address range (which the schema already enforces via minItems/maxItems) but adds nothing about page_size or chain 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 — batching NFT ownership lookups across multiple addresses — and the phrase 'in one call' makes the batch nature explicit. It doesn't name the single-address sibling (cortex_nft_ownership) it is meant to replace, so sibling differentiation is left to inference.

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

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

The description implies the tool is for multi-address work but never states when to use it versus cortex_nft_ownership or the other cortex_aggregate_* tools. No exclusions, prerequisites, or alternative-selection guidance are 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?

With no annotations, the description carries the full burden, but it does add genuine value by disclosing the cost model ($0.004 USDC per id). It does not cover auth requirements, rate limits, error behavior, or return format, which leaves real gaps for a paid external-provider call.

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

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

Two short sentences, front-loaded with the core purpose and then the cost/limit detail. Every clause earns its place 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 simple one-parameter batch lookup this covers purpose, scope, and cost adequately, and no output schema exists so return values need not be explained. But it omits sibling routing against cortex_prices/cortex_token_price and any auth or failure context, leaving the agent under-informed on selection.

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 there is a single parameter fully documented with an example and 1-50 bounds. The description's '1-50 ids' merely restates the schema constraint, so 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 (batch spot USD prices for many coins) and provider (CoinGecko), which distinguishes it from single-token lookups. However, it does not explicitly name or differentiate from close siblings like cortex_prices or cortex_token_price, so the distinction is left to inference.

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

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

The word 'Batch' implies use when pricing many coins, but there is no explicit when-to-use guidance, no mention of when to prefer a single-token tool, and no named alternatives among the many price-related siblings. The agent must guess the routing.

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

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

With no annotations, the description carries the full burden. It usefully discloses cost ($0.004 USDC per address) and the 1-20 batch range, which are real behavioral traits beyond the schema. It says nothing about auth needs, return format, pagination, or partial-failure behavior across a batch.

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

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

Two tight sentences with the core purpose front-loaded and the pricing detail second. No wasted words, though the pricing sentence is commercial rather than strictly operational.

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 batch tool with no annotations and no output schema, the description covers purpose, cost, and batch size but omits chain support (an enum-like list only in the schema), the meaning of limit, and any hint about the returned transfer shape. Adequate but with clear gaps.

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

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

Schema coverage is only 33% (only 'chain' is described), so the description should compensate, and it partially does by restating the 1-20 address constraint and tying cost to the addresses parameter. The 'chain' and 'limit' parameters receive no added meaning from the description, and limit is undocumented in both places.

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 action ('Batch normalized transfers') plus scope ('across addresses in one call'), which cleanly separates it from the singular cortex_tx_history sibling. It never names an alternative explicitly, but the batching scope makes the distinction inferable.

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

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

Usage is implied by the batching scope and the '1-20 addresses' bound, and the per-address pricing gives an agent a cost reason to choose this for multi-address work. However, there is no explicit when-to-use versus cortex_tx_history, nor any exclusion guidance (e.g. use the single-address tool for one lookup).

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

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

With no annotations, the description carries the full behavioral burden. It discloses a genuinely useful trait beyond the schema: the x402 paid model at $0.004 USDC on Base per call, which an agent needs to know before invoking. However, it says nothing about return shape, error behavior, rate limits, or auth requirements.

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 with no filler, and the core purpose is front-loaded ahead of the pricing note. The first sentence is a bare fragment rather than a sentence, which is a minor structural weakness but keeps the definition tight.

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

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

There is no output schema and no annotations, so the description must explain what a caller receives; it never states what a block response contains (header fields, transactions, etc.). For a paid data-fetch tool with zero structured coverage of its result, this is a notable gap.

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 fully documented in the schema (block accepting decimal/hex/'latest', chain enumerating five networks). The description only restates the accepted block forms and adds that the provider is Alchemy, adding little meaning beyond structured data. Baseline 3 applies.

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

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

The description identifies the resource (a block) and its scope (by number or 'latest', on a named chain, sourced via Alchemy), which is enough for an agent to distinguish it from sibling tools that all deal with balances, prices, NFTs, and history. It is a noun fragment rather than a clear verb+resource statement, but the purpose is unambiguous.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternative tools (e.g., cortex_gas_oracle for fee data). The only routing-adjacent signal is the cost disclosure, which acts as an implicit gate but does not tell the agent when this tool is the right choice.

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?

No annotations are provided, so the description carries the burden. It does disclose one meaningful behavioral trait — the call is free (no payment terms charged to the caller) — which is genuinely useful given 'payment terms' is part of the returned payload. However, it says nothing about auth requirements, rate limits, or whether the call is read-only, though the zero-parameter shape makes the risk low.

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 compact sentence with the most decision-relevant token ('Free') front-loaded, followed by an enumeration of returned content. No filler, though 'discovery index' is a slightly opaque label.

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

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

With no output schema and no annotations, the description does useful work by enumerating the categories of information returned, partially compensating for the missing output contract. It still leaves the agent guessing at the exact shape of the response and at whether this is a prerequisite call for the sibling data tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema coverage is 100% but trivially so for an empty object.

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

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

The description names the resource precisely — service capabilities, supported chains/providers, payment terms, discovery index — which is clearly distinct from the data-retrieval siblings (balances, prices, tx_history). The verb is implicit ('returns/lists') but the content of the resource is unambiguous, so an agent can tell this is the service-metadata endpoint.

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

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

No explicit when-to-use statement or named alternatives, but the listed contents (capabilities, supported chains/providers, discovery index) strongly imply this is the discovery/introspection call an agent makes before invoking data tools. The 'Free' prefix is a mild cost signal rather than 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?

With no annotations, the description carries the full behavioral burden. It discloses important traits: the x402 payment requirement ($0.040 USDC on Base per call) and the 5-chain cap. However, it omits read-only nature, error/failure behavior, and rate limits.

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

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

Two tight sentences, the core capability is front-loaded, and the cost constraint follows. 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 2-parameter tool with no output schema and no annotations, the description names the compared dimensions and the payment model, which is largely sufficient. Return formatting details are understandably left out.

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 50%; the description references both parameters conceptually ('one contract address' and 'up to 5 chains'). That said, the 5-chain limit and same-address assumption already appear in the schema, so the added meaning is marginal.

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

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

States a specific verb (Compare) plus resource (one contract address across chains) and enumerates what is compared (price, activity, deployment) in one call. This cleanly distinguishes it from the sibling single-chain and aggregate 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 phrase 'in one call' implies the efficiency rationale for using this over per-chain calls, but no alternative tool is named and no when-to-use/when-not conditions are given. Usage is inferable but not explicit.

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?

With no annotations, the description carries the full burden, and it does disclose two real behavioral facts: the data source (Alchemy) and the paid cost model ($0.004 USDC on Base per call), which is genuinely useful for cost-aware agents. However, it says nothing about freshness, caching, failure modes, or what the response contains.

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 with zero padding, and the core purpose (gas fees for a chain) is front-loaded ahead of the source and payment metadata. Every clause 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 read tool with no output schema or annotations, the description covers purpose, data provenance, and cost. The only real gap is the shape of the returned fee data (units, fields), which an agent must guess.

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

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

Schema description coverage is 100% and the single 'chain' parameter already lists the valid values (ethereum, base, arbitrum, polygon, optimism) plus a default, so the schema does the heavy lifting. The description adds no format or semantic detail beyond it, warranting the baseline 3.

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

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

States a specific verb and resource: retrieves 'current base fee + priority fee (gas prices) for a chain.' The gas-price resource is distinct from the price-oriented siblings (cortex_prices, cortex_token_price, cortex_aggregate_prices), so an agent can separate it by topic, though the description never names an alternative explicitly.

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

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

The phrase 'for a chain' implies the usage context, and the gas-fee subject matter is inherently self-routing, but there is no explicit when-to-use, when-not-to-use, or named alternative among the 17 siblings. Usage is left to inference.

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

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

With no annotations, the description carries the full disclosure burden. It adds real value by revealing the paid model ($0.004 USDC on Base per call via x402) and the upstream provider, but omits pagination behavior, rate limits, or auth requirements.

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

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

Two tight sentences with zero filler, leading with the resource and scope before the cost note. Every clause 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 paid read tool with no annotations and no output schema, the description covers cost and source but leaves pagination (undocumented page_size) and return shape unaddressed. Adequate but with clear gaps.

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

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

Schema coverage is 67%: chain and address are documented in the schema, but page_size carries no description. The prose adds nothing beyond what the schema already provides, 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?

Clearly states the verb+resource: NFTs owned by a wallet on a given chain, and names its data source (Alchemy NFT API). However, it does not distinguish itself from the sibling cortex_aggregate_nfts, leaving ambiguity about which NFT tool to use.

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

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

No guidance on when to use this tool versus alternatives such as cortex_aggregate_nfts or cortex_aggregate_balances. The only context is the per-call cost, which is 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?

With no annotations provided, the description carries the full burden. It discloses useful behavioral traits: it is free, served locally, and involves no upstream call, which helps the agent understand cost and latency. However, it does not state whether it is read-only, idempotent, or what the output format looks like, leaving some gaps.

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 a single, front-loaded sentence that conveys the key points: free, complete tool/price table, local, and no upstream call. Every phrase earns its place and there is no wasted text.

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 (zero parameters, no output schema, no annotations), the description provides enough context to understand its purpose and key operational characteristics. It could be improved by briefly describing the structure of the price table (e.g., what 'price' means in this context), but it is largely 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 tool takes zero parameters, so the baseline score is 4. The description does not need to explain parameter usage, and it appropriately focuses on what the tool returns rather than how to invoke it.

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 resource: the complete tool/price table for the MCP gateway. It distinguishes itself from sibling tools by clarifying that it is about this gateway's own pricing (served locally), not token or market prices. However, it lacks an explicit verb, so it is slightly less than a perfect 5.

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

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

The description implies usage by noting it is 'Free' and 'served locally, no upstream call,' suggesting the agent should use it when it needs the gateway's tool/price information without incurring network cost. It does not explicitly say when to use this versus alternatives, but the context is clear enough for an implied guidance 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the paid x402 model and exact cost per call ($0.004 USDC on Base), which an agent must know before invoking, but it says nothing about return format, pagination relative to max_tokens, or behavior on unsupported/misspelled chains.

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 with zero waste; the core capability is front-loaded and the cost caveat follows. Every clause 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 read-only tool with no output schema and no annotations, the description covers purpose and cost but omits return shape, ordering, and error semantics on invalid chains. Adequate minimum, but not complete for a paid multi-chain API 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 75%, so the schema already documents chain, tokens, and address. The description adds no parameter-level detail and is silent on max_tokens, the one undocumented parameter (default 50, max 200), leaving its pagination role unexplained.

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

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

Names a specific verb (fetch) and resource (ERC-20 token balances) scoped to a wallet on a chain, and credits the upstream provider (Alchemy Token API). It does not explicitly contrast with the close sibling cortex_aggregate_balances, so an agent must infer the single-chain vs. multi-chain distinction itself.

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 'for a wallet on a chain' implies the single-chain scope, which separates it from cortex_aggregate_balances, but there is no explicit when-to-use/when-not guidance or named alternative. Usage is only inferable.

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?

With no annotations the description carries the full burden, and it does disclose meaningful traits beyond the schema: every fact carries source + checked_at (provenance/freshness) and the call is x402 paid at $0.030 USDC on Base. It does not restate read-only semantics or describe response structure, 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?

A single dense sentence that front-loads the core value proposition (full profile in one call), then trailing details on provenance and cost. It is slightly overloaded with the payment and provenance clauses but every element 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 composite profile tool with no output schema, the description enumerates the payload and discloses cost and data provenance, which is most of what an agent needs to call it correctly. Remaining gaps are minor: no return-shape or pagination notes.

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 chain/coin_id/contract are already documented, and the baseline is 3. The description tangentially maps 'optional age/liquidity/market-cap' to coin_id, but adds no syntax, format, or default details 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?

Names a specific resource (token profile) and enumerates exactly what it returns: deployment, metadata, spot price, 24h change, age/liquidity/market-cap, recent activity. The 'one call' framing distinguishes it as a composite tool versus the narrower cortex_token_price and cortex_token_risk, but it never names a sibling explicitly.

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

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

The listing of bundled fields implies you use this when you want a full profile rather than a single metric, and 'optional age/liquidity/market-cap' hints that extra context requires coin_id. There is no explicit when-to-use/when-not guidance and no routing against the many sibling price/risk/aggregate 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?

With no annotations, the description carries the full burden and does disclose a meaningful behavioral trait: x402 paid at $0.004 USDC on Base per call, which is critical for an agent to know before invoking. It also clarifies the price is 'spot' (not historical). It stops short of describing error/fallback behavior when a token isn't found.

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, and the core purpose plus payment cost are front-loaded. Every clause 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 read-style price tool with no annotations and no output schema, the description covers purpose, inputs, and cost. It could add a note on what the response contains (e.g., currency/price fields) to fully close the loop, but it is largely complete.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine value by stating the either/or relationship between 'id' and 'contract'+'chain' that the schema alone does not make explicit. It also supplies concrete id examples ('ethereum', 'usd-coin').

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: spot USD price for a token/coin. An agent can distinguish this single-token price lookup from siblings like cortex_prices or cortex_aggregate_prices, though the description doesn't explicitly name those alternatives to sharpen the distinction.

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 two input paths (id OR contract+chain), which functions as usage guidance, but gives no explicit when-to-use/when-not guidance relative to the price-related siblings. Usage 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?

No annotations are provided, so the description carries the full burden. It usefully discloses a real behavioral trait — an x402 payment of $0.020 USDC on Base per call — and notes the response includes per-claim evidence, but says nothing about auth flow, latency, or failure/rate-limit behavior for a paid external call.

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

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

Two compact sentences that front-load the deliverable and then append the cost/payment detail. No filler, though the parenthetical list is dense shorthand rather than explanatory.

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 annotations and no output schema, the description should do more: it hints at return structure ('per-claim evidence') but does not describe the verdict shape, scoring dimensions, or when results are inconclusive. The payment model is covered, but the analytical output remains underspecified.

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% (chain enum-style list, coin_id purpose, contract pattern), so the schema already documents all three parameters well. The description adds no parameter detail beyond what the schema provides, 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 deliverable (a 'token risk verdict') and enumerates its components (age, liquidity, contract checks, suspicious-transfer scan), which distinguishes it from price/intel siblings like cortex_token_price and cortex_token_intel. It does not name those siblings explicitly, so the differentiation is inferential 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?

There is no guidance on when to use this tool versus the similarly-scoped cortex_token_intel, cortex_token_price, or cortex_whale_alerts. Usage must be inferred entirely from the tool name and the verdict components listed.

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?

No annotations are provided, so the description carries the full burden. It does disclose a genuinely useful non-obvious trait — the tool is pay-per-call ($0.004 USDC via x402 on Base) — but says nothing about auth requirements, rate limits, pagination, or result ordering for a query tool.

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

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

Two tightly written sentences with the data scope front-loaded and the cost note appended. Nothing is padded, though the parenthetical API reference is more provenance than agent-actionable detail.

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

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

With no output schema and no annotations, the description should cover return shape and paging behavior. It hints at normalization but omits pagination (the limit param implies it) and the semantics of from_block versus chain selection, leaving real gaps for a 4-param query 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 75% (chain, address, from_block documented; limit undocumented), so the schema already does most of the work. The description adds no syntax, default, or format detail beyond what the schema provides, which is the expected baseline at this coverage level.

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

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

The description names the resource precisely ("normalized transactions for an address on a chain") and cites the upstream API (Alchemy Transfers API), so an agent knows exactly what data comes back. However, it never distinguishes itself from the sibling cortex_aggregate_tx_history, so the agent cannot tell which of the two history tools to pick.

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

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

There is no when-to-use guidance and no mention of the obvious alternative, cortex_aggregate_tx_history, which likely covers the multi-chain/aggregated case. The only routing signal is the implicit single-chain scope, which the agent must infer.

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?

With no annotations, the description carries the full burden, and it does disclose two useful traits: the data source (Alchemy) and the x402 pay-per-call cost ($0.006 USDC on Base). It omits error behavior, what happens for unknown addresses, and pagination semantics, so disclosure is partial.

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

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

Two compact sentences, front-loaded with the returned data categories and followed by the cost note. Every clause carries information; there is no padding.

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

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

For a paid, multi-parameter data tool with no output schema and no annotations, the description covers what data comes back and what it costs, but leaves return format, pagination (limit), and failure modes unaddressed. Adequate but with clear gaps.

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

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

Schema description coverage is 67%: chain and address are documented in the schema, while limit is not. The description adds no parameter-level meaning (no address format, chain options, or limit semantics), so the schema does the heavy lifting and the description leaves a real gap on limit.

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 resource (wallet profile) and enumerates the data categories it returns: balances, holdings, recent activity, and counterparty relationships. An agent understands the tool's scope, but nothing distinguishes it from siblings like cortex_token_balances or cortex_tx_history that cover overlapping data.

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

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

There is no guidance on when to choose this aggregated profile over the many sibling tools (cortex_aggregate_balances, cortex_tx_history, cortex_token_balances). The only usage-adjacent statement is the pricing note, which tells the agent it costs money but not when it is worth spending.

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?

With no annotations, the description carries the full burden and does disclose the two things an agent most needs: the data source (Alchemy) and the paid x402 model ($0.030 USDC on Base per call), which is a real gating fact before invocation. It omits alert freshness/latency semantics (real-time stream vs historical scan) and any rate or pagination behavior.

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

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

Three short sentences, each load-bearing: what it returns, how to widen the scope, what it costs. The scoping instruction is front-loaded before the payment note, so the most actionable line lands first.

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 does name the returned fields (tx hashes, timestamps), which is the main gap it needed to close. Remaining gaps are the freshness/recency semantics of an alert feed and how limit interacts with the default threshold, neither of which is stated anywhere.

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 only 50% (chain and address described; limit and min_usd not), so the description must compensate. It does so meaningfully for address, clarifying that omitting it switches to a chain-wide scan rather than returning nothing, which the schema's 'Optional wallet to watch' 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?

Names a specific resource ('large-transfer / accumulation alerts') and discloses the payload ('tx hashes + timestamps') plus the data source (Alchemy). No sibling covers the same ground, so an agent can route here without opening a schema.

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

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

'Omit address for a chain-wide scan' gives explicit conditional usage for the two operating modes of this tool. It stops short of naming alternatives or stating when not to use it (e.g. versus cortex_tx_history or cortex_wallet_intel for address-scoped lookups).

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