Chord

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

Annotations already declare readOnly=true, destructive=false, openWorld=true, so the safety profile is covered. The description adds genuinely useful context beyond that: it draws on many data sources, takes 10-60 seconds (latency expectation), and requires an API key (auth prerequisite). It doesn't describe the shape of the returned answer, but for a read-only tool this is solid.

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

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

Three tight sentences with zero filler. The core purpose leads, followed by scope, then the operational facts (latency, auth) that an agent needs before invoking.

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 no-output-schema, read-only analysis tool, the description covers the essentials: what it does, latency, and auth requirements. It stops short of explaining the answer's format or whether follow-up context persists, which is a minor gap given idempotentHint=false.

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 (question up to 1,000 chars; wallet for resolving 'my PnL'). The description adds no syntax, format, or example detail for either parameter, so baseline 3 applies.

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

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

States a specific verb (ask) and resource (Chord's analyst) in plain language, plus the domains covered (markets, tokens, wallets, perps, macro). The 'plain language' framing implicitly separates it from the structured-data siblings like chord_token or chord_trades, but it never names an alternative, 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?

Usage context is implied: use this for open-ended natural-language questions across the listed domains. However, it gives no explicit when-to-use/when-not guidance and never points to the specific chord_* tools for structured queries, which is the key routing decision among 17 siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds one genuinely useful behavioral fact — the data comes from Chord's own index rather than aggregated external sources — but says nothing about ordering, pagination, or how gaps/missing candles are handled.

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

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

A single front-loaded sentence with zero filler. It is efficient, though the extreme brevity leaves useful context unsaid rather than adding any waste.

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 OHLCV abbreviation and the 'from Chord's own index' provenance note cover the essentials for a read-only time-series endpoint, and annotations carry the safety profile. Missing only secondary details like row ordering and default-window behavior, which the schema partly signals via defaults.

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%: timeframe, chain, limit bounds, and chain-specific address formats are all documented in the schema itself. The description contributes no additional parameter meaning, so the baseline of 3 applies.

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

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

States a concrete resource and return shape: OHLCV candles for a token, sourced from Chord's own index. That provenance phrase distinguishes it somewhat from trade- or pool-oriented siblings like chord_trades, though it never names an explicit alternative.

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 statement of when to reach for this tool versus chord_trades or chord_token, and no prerequisites or exclusions. The agent must infer that this is the price-history endpoint from the name alone.

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

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

Annotations declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is already covered. With no output schema, the description usefully carries the return contract by naming the fields (native asset, anchors, capability list) an agent will get back.

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: the payload contents first, the calling instruction second. No filler, and the parenthetical capability list is load-bearing rather than decorative.

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 discovery tool with no output schema, the description supplies both the fields returned and the vocabulary of capabilities, which is everything needed to decide whether to call it and what to expect.

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

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

The tool takes zero parameters, which is the baseline 4 case. There is nothing parameter-related the description could add, and schema coverage is 100%.

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

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

States a specific resource (the chains Chord serves) and enumerates exactly what it returns: native asset, anchors, and per-chain capabilities. The capability vocabulary (overview, tokens, trades, candles, wallet PnL, smart money, holders, LP, quote, swap) makes it unmistakable against siblings like chord_status or chord_overview.

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?

'Call this first when unsure what a chain supports' gives an explicit trigger condition for invoking it. It stops short of naming an alternative tool or a when-not-to-use case, so it is clear context rather than a full routing rule.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact: holder data exists only on some chains, so results may be unavailable depending on chain. It says nothing about pagination, ordering, or what happens on a chain without a holder ledger.

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

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

A single front-loaded sentence with no filler, and the availability caveat is placed where it matters. The parenthetical and trailing clause are slightly compressed to the point of ambiguity about which chains actually qualify.

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 carry the burden of conveying the return shape, and 'balances by address' minimally does that. However, for a 3-parameter, cross-chain data tool it omits the unsupported-chain behavior, default/max row semantics, and any result ordering, leaving the agent with only a partial picture.

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 chain, address and limit are already documented in-schema, including the EVM vs Solana address format distinction. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

The description names a specific resource — a token holder ledger returning balances keyed by address — which is a distinct artifact from siblings like chord_token or chord_wallet. It does not name or contrast any sibling tool, and lacks an explicit verb, so an agent must infer that this is a read of holder balances. Clear, but no sibling differentiation.

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

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

There is no when-to-use guidance and no named alternative for holder-style queries. The clause 'on the chains that keep one' implies an availability condition, but it neither lists which chains qualify nor points the agent to chord_chains (only the schema does).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that results are ranked by volume/fees/TVL/fee-TVL, which is useful context, but it does not disclose default sort order, pagination, or data freshness.

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 fragment with no filler, and the ranking metrics are front-loaded. It is terse enough that it reads more like a label than a sentence, but nothing is wasted.

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

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

With only two fully documented parameters, no output schema, and annotations covering the safety profile, the essentials for invocation are present. However, the description never states the default sort or whether the ranking is applied server-side, which matters for a tool whose entire purpose is ranked output.

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 chain (enum plus pointer to chord_chains) and limit (default 25, 1-100) both documented. The description adds nothing 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?

The description names the resource (pools) and the audience/ranking basis (for a liquidity provider, ranked by volume, fees, TVL, fee/TVL), which lets an agent distinguish it from chord_lp_positions and chord_tokens. It lacks an explicit verb like 'list' or 'rank', but the intent 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 when-to-use guidance, no mention of the sibling chord_lp_positions (which an LP might confuse it with), and no statement of prerequisites or ordering. The audience hint ('for a liquidity provider') only weakly implies usage.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld behavior, so the safety profile is covered. The description adds the returned content (range, value, fees, in/out of range), which is genuinely useful given there is no output schema, but says nothing about empty results or value units.

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 that front-loads the resource and scope before the returned fields. 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 two-parameter read tool, the description tells the agent the scope and the key return fields, and annotations cover safety; no output schema exists so this is the only cue to the payload. Missing only edge-case behavior (no positions found, value denomination), which is minor.

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 documented, including chain enum guidance pointing at chord_chains and the address format per chain. The description only restates 'a wallet' and 'one chain', adding no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

Names the resource (liquidity positions) with explicit scope: one wallet, one chain, and lists the fields carried. It implicitly separates itself from chord_lp_pools (pool discovery vs. a wallet's positions), though it never names that 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?

There is no statement of when to use this versus chord_lp_pools, chord_wallet, or chord_wallet_trades, and no prerequisites or exclusions. Usage is only inferable from the purpose text.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds genuinely useful scope context — a fixed 24h window and the metric set — but says nothing about response shape, aggregation guarantees, or behavior for chains with no indexed venues.

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

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

One front-loaded sentence with a colon-delimited metric list and zero filler. It is tight, though the fragmented phrasing ('A chain's last 24 hours on the venues Chord indexes') is slightly elliptical and could read more naturally without gaining length.

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

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

With no output schema, the description correctly carries the burden of stating what is returned, which it does via the metric enumeration. For a one-parameter read-only tool with complete annotations and full schema coverage, this is nearly sufficient; only the response shape and empty-chain behavior remain 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 description coverage is 100% and the single enum parameter is documented in the schema, including a pointer to chord_chains for supported keys. The description adds no syntax or format detail beyond that, 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?

The description names the resource (a chain), the fixed time window (last 24 hours), the data source (venues Chord indexes), and enumerates the returned metrics (volume, swaps, venue share, hourly buckets). This is specific enough for an agent to know it is a chain-level 24h aggregate, though it does not explicitly contrast itself with siblings like chord_candles or chord_trades.

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, when-not-to-use, or named alternative; the agent must infer from the metric list that this is the high-level summary tool. The mention of 'venues Chord indexes' hints at coverage but gives no routing guidance among the 17 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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds genuinely non-obvious behavior: dual-router routing with Chord-first fallback, the 2-minute quoteId expiry, and that supplying a taker changes the response to include a transaction plus simulation. These are behaviors an agent cannot recover from the schema.

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

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

Three dense sentences, front-loaded with the core purpose, then routing behavior, then unit/ID semantics. Nearly every clause carries information; the opening superlative ('Best swap quote') is the only mild marketing filler.

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

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

With no output schema, the description does the work of describing the return (a quoteId valid for 2 minutes, and optionally a transaction plus simulation when taker is provided). Solana's REST-only path is documented in the schema but not in the description, which is a minor gap for an EVM-focused tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: the zero address maps to the native asset, and the taker parameter upgrades the response to include a transaction and simulation. Amount unit semantics are repeated from the schema rather than extended.

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 ('swap quote') with scope ('on an EVM chain') and an implicit contrast to the execution sibling by promising a quoteId rather than a transaction. It never names chord_swap_tx or another sibling explicitly, so 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?

The description explains routing priority (Chord's router first, another aggregator as fallback), which is useful operational context, but it gives no explicit when-to-use guidance relative to siblings like chord_swap_tx or chord_ask. The 2-minute quoteId lifetime implies a follow-up execution step but that is left for the agent to 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?

Annotations cover the safety profile (read-only, idempotent, open-world), so the bar is lower. The description adds genuine behavioral context: it returns multiple candidates rather than one, and warns that similar tickers are common so addresses must be compared. It does not mention result limits or pagination, keeping it short of 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 tightly written sentences, front-loaded with the core action and followed immediately by the most important caveat. No waste.

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 read-only search with no output schema and full annotation coverage, the description supplies the essential caveat about ambiguous results. It lacks detail on result count, ordering, or ties to chord_token, which would 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?

Schema coverage is 100%, so both parameters are already documented. The description restates the accepted query forms (symbol, name, address) but adds no syntax, format, or validation detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Find) and resource (token) with explicit scope (on one chain, by symbol/name/address). Distinguishes itself from the sibling chord_token, which presumably resolves a single known token rather than searching.

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?

Implies usage (search when you don't have the exact address) but never names the alternative chord_token or states when this is preferable. The only guidance is the implicit warning about similar tickers.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior beyond that: rows are ranked by profitability and bot wallets are filtered out, plus a coverage caveat that not every chain supports the board. It does not mention pagination or the meaning of the ranking metric, keeping it short of 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, with the core scope ('wallets ranked by profit on one chain') front-loaded and the caveat second. Nothing could be trimmed 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 read-only list endpoint with no output schema, the description conveys the shape of the return (ranked wallets) and the data-quality filtering, which is roughly what an agent needs. It lacks any hint about the ranking field or result size beyond the limit parameter, a minor gap given the fully documented schema and annotations.

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%: each parameter already documents its defaults, ranges and enum values, including the per-chain day-window rules. The description adds no parameter-level detail, so the baseline 3 is appropriate.

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

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

The description states the specific resource (wallets), the ranking criterion (profit), the scope (one chain), and a data-quality guarantee (bots removed). This is a distinct verb+resource statement that separates it from nearby siblings like chord_wallet and chord_holders.

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 line 'Not every chain has this board' gives a useful availability caveat and implicitly routes the agent to chord_chains for support, but it never states when to prefer this board over alternatives such as chord_holders or chord_wallet, nor any prerequisites. Usage is implied rather than specified.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. Because there is no output schema, the description usefully carries the burden of disclosing what comes back (routing engine state, trade index staleness, status page link), which is behavior-adjacent content the annotations do not 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?

A single front-loaded sentence that names the resource first and then the three concrete outputs. No filler, no redundancy, and the colon structure keeps the enumeration scannable.

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 parameters, a fully covered empty schema, and annotations covering the safety profile, the description supplies most of what an agent needs by enumerating the returned signals. It could go slightly further on what 'every chain' means in scope or how the health values are shaped, but no output schema exists to cover that either, so the gap is modest.

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 zero-parameter schema applies, and nothing in the description misrepresents the calling surface.

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

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

States a specific resource (live health of every chain) and enumerates the concrete signals returned: routing engine state, indexed-trade freshness, and the status page link. This is far more specific than a name restatement, though it never explicitly contrasts itself with the similarly scoped sibling chord_overview.

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 'Live health' implies the moment to use it (checking system/chain operational state), but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings like chord_overview or chord_chains. 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description reinforces this by explaining why: nothing is sent, the taker's own wallet signs and broadcasts. It also discloses that the response bundles an approval and a simulation, which annotations cannot express. It stops short of stating expiry, refresh, or failure behavior of the returned payload.

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

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

Three sentences, front-loaded with what the tool returns, then the safety constraint, then the invocation. No filler; every sentence carries distinct information.

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

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

With no output schema, the description carries the return-value burden and does so well by naming the transaction, approval and simulation. The main residual gap is the quoteId-vs-full-parameters branch: it does not say which of tokenIn/tokenOut/amount become unnecessary when quoteId is supplied.

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 57%; chain, taker, tokenIn and tokenOut are documented in the schema. The description adds real meaning for quoteId (it comes from chord_quote and is an alternative to passing full parameters) but leaves amount and slippageBps unexplained in both places. Baseline 3 is appropriate given the partial coverage.

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 ('The UNSIGNED transaction for a swap') and enumerates the three artifacts returned: the transaction, the approval, and a taker simulation. It also names the sibling that feeds it ('a quoteId from chord_quote'), so an agent can separate it from chord_quote 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 invocation path: pass a quoteId from chord_quote, or the full parameters. That routes the agent correctly, but it never states when this tool is inappropriate (e.g. Solana, which the schema notes is REST-only) or what happens if both a quoteId and full parameters are supplied.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description usefully adds the shape of the return payload (price, volume, trades, venues, index metadata), but says nothing about failure modes for invalid chain/address, or whether weather/index metadata can be 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?

A single tight sentence with the key scoping constraint front-loaded. 'What the index knows about it' is slightly vague filler but does signal extra metadata fields, so it mostly 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?

With only two fully documented parameters and no output schema, the description's enumeration of returned fields (price, volume, trades, pools/venues, index info) is enough for an agent to decide to call it. Missing only the list-vs-detail routing relative to chord_tokens.

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%: both chain (with enum plus pointer to chord_chains) and address (EVM vs Solana base58, case-sensitive) are documented in the schema. The description adds no parameter-level detail beyond that, 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 resource and scope ('one token on one chain') and enumerates the payload: price, 24h volume and trades, pools or venues, and index metadata. However it never names the adjacent siblings (chord_tokens for listing, chord_candles for OHLC, chord_trades for trade history), so the agent must infer the boundary 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?

There is no when-to-use or when-not-to-use guidance and no named alternative. The phrase 'one token on one chain' implies a single-entity lookup versus the plural chord_tokens, but that inference is left entirely to the reader.

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

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

Annotations already cover the read-only/idempotent safety profile, and the description adds a genuinely useful behavioral detail: sort names are chain-dependent and an invalid one is answered with the allowed list rather than failing silently. It does not discuss rate limits or result sizing beyond what the schema states.

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: what the board is first, then the chain-specific sort caveat. Front-loaded and free of filler.

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

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

With no output schema, the description correctly enumerates the returned columns, and the sort/chain caveats plus the chord_chains pointer cover the main pitfalls. Minor gaps remain (no pagination hints, though limit is documented 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 coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: sort tokens vary per chain and errors reveal the permitted values. That extra semantic guidance on the sort parameter earns it above baseline.

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

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

States the specific resource (24h token board) and enumerates the returned fields (price, volume, trades, change), which separates it from the singular chord_token. It never explicitly names the sibling it differs from, so it falls short of a 5.

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

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

Usage context is implied by '24h token board' and it points to chord_chains for chain capabilities, plus explains that a bad sort key returns the allowed list. However, it gives no explicit when-to-use-this-vs-chord_token or chord_candles guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds useful output-shape context (which fields come back) and the caveat 'where it is known', which signals that wallet attribution can be missing — a genuine behavioral detail 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?

A single front-loaded sentence with no filler; the field list is compact and immediately useful. The trailing clause 'and the wallet where it is known' is slightly awkwardly phrased but still information-dense rather than wasteful.

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 correctly compensates by listing the returned fields, which is the most important omission it could have covered. What remains unstated — ordering (only implied by 'newest'), default/pagination behavior, and real-time vs cached freshness — is minor for a simple read tool with fully described parameters.

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 chain, address and limit are already documented with enum values and format notes for EVM vs Solana addresses. The description only implies the address parameter via 'of a token' and adds no new format, ordering or default-limit semantics, so the baseline 3 applies.

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

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

States a specific verb+resource — the newest swaps of a token — and enumerates the returned fields (side, USD size, price, venue, wallet). The 'of a token' scoping implicitly distinguishes it from the sibling chord_wallet_trades, but the description never names that sibling or otherwise explicitly differentiates itself from tools like chord_swap_tx.

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, no prerequisites, and no named alternatives. An agent must infer from 'newest swaps' that this is for recent token-level trade activity rather than aggregated candles (chord_candles) or a single transaction lookup (chord_swap_tx).

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety bar is low. The description adds real context beyond that: results are broken out per token into realised versus open PnL, and the time window varies by chain and is reported back, warning the agent not to assume a fixed interval.

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, zero filler, with the core definition front-loaded and the window caveat following it. Every clause carries information.

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

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

With no output schema, the description must convey what comes back, and it does: per-token realised and open PnL plus the applicable window. Nothing critical is missing for a two-parameter read-only tool, though it never clarifies chain-specific window semantics or result shape beyond the token breakdown.

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%: the chain enum, its pointer to chord_chains, and the address-format note for wallet are all documented in the schema. The description adds nothing beyond that, 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 resource and metric: a wallet's realised and open PnL, per token, on one chain. That is materially more precise than the bare title 'Wallet PnL'. It does not explicitly distinguish itself from the nearby chord_wallet_trades sibling, so it falls short of a 5.

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

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

No when-to-use, when-not-to-use, or alternative tool is named. The phrase 'on one chain' hints that per-chain calls are required, but the agent gets no guidance on choosing this over chord_wallet_trades or chord_overview for wallet analysis.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds two traits they do not: results are limited to 'recent' activity and to a single chain, and coverage is chain-dependent. It still omits how far back 'recent' extends and whether results are capped/paginated.

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, no filler, with the core resource statement front-loaded before the availability caveat. 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 simple two-parameter, fully-documented schema with annotations covering safety and no output schema, this is close to sufficient. The remaining gap is that 'recent' is undefined with no hint of result volume, so an agent cannot anticipate whether it receives five rows or five hundred.

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 the chain enum and address-format notes documented inline, so the baseline is 3. The description adds only marginal meaning ('one chain' per call) and otherwise defers parameter detail to the schema and to chord_chains.

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

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

The description names a specific resource and scope: a single wallet's recent swaps restricted to one chain. That is enough for an agent to separate it from chain-wide or token-centric siblings like chord_trades, though no sibling is named explicitly to sharpen the boundary.

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 discloses a real precondition ('Not every chain has this') and routes the agent to chord_chains for availability, which is useful. However, it never states when to pick this tool over chord_trades, chord_wallet, or chord_smart_money, so tool-selection guidance is only implied.

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