AlphaGrowth

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's added value is the non-obvious data freshness split: metrics are lagged one day while ecosystem counts are current, and the source is free AlphaGrowth data. It doesn't disclose return shape, pagination, or whether unknown slugs error or return empty, which are the remaining behavioral 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?

Three tight sentences, front-loaded with the tool's identity, then the freshness caveat (the highest-risk misreading), then the cross-reference. No filler and nothing redundant with the schema or annotations.

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

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

There is no output schema, so the description carries the burden of describing return content, and it does so by enumerating the metric families returned. Combined with the lag caveat and the sibling cross-references, an agent has everything it needs to call this correctly.

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

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

Schema coverage is 100% and the single `slug` parameter is already documented with an example and the reference to `chains`, so the schema does the heavy lifting. The description adds only the useful note that the same slug is reused by project_metrics. 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 names the specific resource (a blockchain's AlphaGrowth chain-compare metrics) and enumerates exactly which values are returned: TVL, transactions, price, social numbers, and ecosystem counts. It explicitly distinguishes itself from project_metrics, which carries the chain's current price, so an agent can route between them 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?

It states the temporal condition that selects this tool (daily snapshots as of `date`, one day ago UTC) and names the alternative for current values (project_metrics with the same slug), plus points at `chains` for the slug. What it doesn't do is frame a general when/when-not rule for historical trend lookups, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real context by attributing the source (AlphaGrowth) and noting the data is free, which tells the agent no auth or cost is involved. It does not mention rate limits or freshness/staleness of TVL figures, 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?

Two sentences, front-loaded with what is returned before the cross-tool guidance; every clause carries information (fields, page size, slug handoff, data source). 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?

With no output schema, the description compensates by enumerating the returned fields, and the pagination/query semantics live in the schema. For a two-param read-only list tool, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and both parameters already carry descriptions ('Page number, 50 chains per page' and the substring-match query), so the description's '50 per page' repeats the schema. It adds only the downstream meaning of the chain slug, which is a marginal gain over the structured fields.

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 ('Blockchains ranked by TVL') plus the exact fields returned: price, market cap, 1d/7d TVL change, project counts, and page size. An agent can distinguish this chain-listing tool from chain_metrics or rank_projects without opening any schema.

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

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

Explicitly routes the agent downstream: use the chain's slug with chain_metrics and its chain_slug as the filter for rank_projects. That names the alternatives and the handoff condition, though it doesn't state when this tool should be skipped in favor of a project-oriented search like find_projects.

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 read-only and closed-world, but the description adds substantive context not in them: historical start date (2024-07-24), the 92-day per-call cap, the default window, and the upstream data source (AlphaGrowth). Return shape is described at a field level (amount, USD value, price).

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 dense sentence that front-loads what the tool returns before parenthetical detail, with constraints and cadence after. No waste, though the nested parentheticals make it slightly harder to scan than a two-clause split would be.

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 still names the returned fields, the aggregation grain, the earliest available date and the call-size limit. An agent has everything needed to call it and interpret the result without opening anything else.

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, and the description adds the window constraint (92-day cap, 30-day default) that the schema itself does not encode. It does not restate the date format or the dao-id lookup, which the schema already handles.

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

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

States a specific verb+resource: daily token holdings of one DAO treasury, with per-token amount, USD value and price, one point per token per UTC day. The 'per token per UTC day' phrasing implicitly separates it from DAO-level siblings like dao_treasury_history/dao_treasury_snapshot, but it never names those alternatives 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?

Gives the operating window (max 92 days per call, last 30 days by default) and the schema points at dao_treasuries for the DAO id, but there is no explicit statement of when to pick this over dao_treasury_history or dao_treasury_snapshot. Usage is implied by granularity rather than declared.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value on top by disclosing the $500 threshold, the descending-value ordering, the returned fields, and the upstream data provider. The only gap is that it doesn't say how the "links" behave or whether results are cached, which is minor for a read-only list.

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

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

Two sentences, front-loaded with the resource, filter, and ordering before the secondary routing hint and attribution. Every clause carries information; the only slight dip is the attribution tail, which aids trust but isn't strictly needed to invoke the tool.

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 the description compensates by enumerating the return shape (total USD value, 24h change, category, top tokens, main chain), which is exactly what an agent needs to decide whether this tool answers the question. Missing only pagination-total behavior and the meaning of the embedded links.

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

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

Schema coverage is 100%, with all three parameters documented (limit range, offset semantics, project slug), so the schema carries the load. The description adds no parameter-level detail such as how project slug interacts with the $500 threshold or whether paging is stable across requests, 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 and resource ("Lists DAO treasuries") plus a hard filter (>$500) and sort order (largest first), which an agent can act on directly. It gestures at the sibling distinction via "Use the links for a DAO's daily history" but never names dao_treasury_history or dao_treasury, so the differentiation from siblings is implied 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?

The clause "Use the links for a DAO's daily history" points an agent toward per-DAO history rather than this aggregate list, which is a real routing hint. However, it never names the alternative tool and gives no exclusion for when to prefer dao_treasury or dao_holdings_history, leaving the agent to infer the boundary.

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 read-only and closed-world safety, so the description only needs to add context — and it does, disclosing the data provenance and the 'free data from AlphaGrowth' condition (no auth/key implied). With no output schema, enumerating the returned fields adds real behavioral value; it stops short of noting freshness or data-source lag.

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. The core action and return shape are front-loaded before the provenance attribution, and 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?

For a one-parameter single-record read with annotations covering safety, the description is nearly sufficient: it names the fields returned in place of a missing output schema and identifies the source. Minor gap: no distinction from dao_treasury_snapshot, which sounds like it could return overlapping data.

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?

Single parameter with 100% schema description coverage, so the schema already tells the agent the id comes from dao_treasuries. The description's 'by id' restates the schema rather than adding format, range, or validity guidance — 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-equivalent ('one DAO treasury by id') and enumerates the payload fields (total USD value, 24h change, category, top tokens, main chain). The 'one ... by id' framing implicitly separates it from the sibling dao_treasuries list tool, though no sibling is named explicitly.

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

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

Usage is implied only: you must already have an id, and the schema notes it comes from dao_treasuries. There is no explicit statement about when to use dao_treasury vs dao_treasury_snapshot, dao_treasury_history, or dao_holdings_history, leaving the agent to infer the boundary.

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 read-only and closed-world safety, and the description adds real behavioral context beyond that: one point per UTC day using the day's last sample, coverage starting 2024-07-24, and a default of the entire history. It does not discuss rate limits or response shape, but the sampling semantics and data window are exactly the kind of detail an agent cannot get from annotations.

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

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

A single sentence, front-loaded with the core resource and unit of measure, with the sampling rule and coverage window following. The AlphaGrowth provenance clause is the only part that is arguably optional, though it explains a data-trust characteristic.

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, three-parameter time-series tool with full schema coverage and no output schema, the definition gives the granularity, sampling rule, start-of-coverage, and default range — enough to call it correctly. The only gap is how it relates to neighboring treasury tools.

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

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

Schema description coverage is 100%, and the parameters carry their own format, defaults, and dao-id cross-reference. The description only restates the whole-history default, adding no syntax or interpretation 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+resource: daily total treasury value in USD for a single DAO. 'History' implicitly distinguishes it from dao_treasury / dao_treasury_snapshot (point-in-time), but no sibling is named explicitly, so the differentiation is inferred rather than stated.

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

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

Usage is implied by the word 'history' and the date-range framing, but the description never says when to pick this over dao_treasury, dao_treasury_snapshot, or dao_holdings_history (which gives per-asset breakdowns). An agent must infer the boundary itself.

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?

Adds genuinely useful behavior beyond readOnlyHint=true and openWorldHint=false: the 'last sample up to 6 days before it' staleness rule, the ordering, the date bounds, and the default. It doesn't state the response shape or how many DAOs are returned, but it discloses the sampling lag that would otherwise cause an agent to misreport 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?

One dense sentence front-loads what is returned, then scope, then ordering, then bounds. The trailing attribution ('Free data from AlphaGrowth') is mild filler but does flag provenance; borderline but acceptable.

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-required-param, read-only snapshot with a fully documented schema, the description covers coverage (every listed DAO), freshness lag, ordering, range, and default. Only the granularity of 'listed DAO' (which universe) and the response fields are left unstated, and no output schema exists to cover the latter.

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

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

Schema coverage is 100% and the schema already carries the format, example, range, and default for 'date'. The description repeats the same range and default rather than adding syntax or edge-case meaning, 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?

Names a specific resource (every listed DAO's treasury value in USD), a unit (one UTC day), and an ordering (largest first). Among siblings like dao_treasury, dao_treasury_history, and dao_holdings_history, the phrase 'every listed DAO ... as of one UTC day' clearly marks this as the cross-DAO snapshot rather than a single-DAO or time-series tool.

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

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

Gives clear context (a daily snapshot for any day since 2024-07-24, default yesterday) that implies when to use this vs. a history tool, but never names dao_treasury_history or dao_treasury as the alternatives an agent should pick when it wants a per-DAO series instead of a cross-sectional snapshot.

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 read-only and closed-world, so the description correctly focuses on behavior: the 50-per-page pagination, that 7d fields are true rolling sums including the latest day, that 24h changes are null when the prior day has no value, and the upstream free data source. The null-handling note is the kind of gotcha an agent could not get from 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?

It leads with the core identity and page size, then adds caveats, with no filler sentences. The long opening clause is dense and could be split, which keeps it from a 5.

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

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

There is no output schema, so the description must convey the return shape, and it does name the key returned concepts: 24h change, chains, version splits, and the 7d fields. Field names and types are not enumerated, but for a three-parameter read tool this is close to sufficient.

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

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

Schema description coverage is 100% and both sort parameters have enums with defaults, so the schema already establishes the full parameter contract. The description only restates the page size that is already in the schema and adds no sorting guidance beyond it, making the baseline 3 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 a concrete verb and resource (protocols ranked by fees or revenue) plus the ranking window, so the agent knows exactly what this returns. It stops short of naming a sibling such as rank_projects or project_metrics, so differentiation is inferred rather than stated.

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

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

Usage is only implied: the description says the data is the latest completed day, which tells the agent this is not a historical or range-query tool, but there is no explicit when-to-use or when-not-to-use guidance and no mention of the alternative ranking tools in the sibling list.

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?

Although annotations already establish readOnlyHint=true and openWorldHint=false, the description adds meaningful behavior: substring matching, TVL-descending ordering, returned fields including slug/category/TVL/market cap, and the is_chain flag. It also discloses the data source, which is useful context beyond the annotations.

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

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

The search behavior and result shape are front-loaded, followed by routing guidance and provenance. The description is dense but compact, and each sentence adds useful selection or interpretation context.

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

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

For a simple read-only search tool, the description supplies the needed result shape even though there is no output schema, and annotations cover the safety profile. The schema handles parameter constraints, so an agent has enough information to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents both query and limit. The description reinforces that query matches name or symbol but adds no new limit behavior or constraints beyond what the schema provides, making the baseline 3 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 a specific verb and resource: finds crypto projects by name or symbol. It also defines ordering, return fields, and distinguishes chain projects by pointing to chain_metrics and project_metrics. This clearly separates it from sibling 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?

It explicitly routes agents to the correct alternatives for chain and coin data: use chain_metrics for the chain and project_metrics for its coin. It also tells agents to use the returned slug with other project tools, providing strong selection guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds valuable behavior context by enumerating what is returned (title, start time, duration, participants, audio url 'when published', timed transcript segments). It flags that audio url is conditional but doesn't cover failure modes for missing/unanavailable transcripts.

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

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

Two sentences, front-loaded with the purpose and then the return shape. No filler, and the key scoping fact (imported Space, ID from search_results) appears 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?

With no output schema, the description carries the return-value burden and does so well by listing all major fields. It is nearly complete for a simple read-only tool, though it omits behavior for invalid IDs or transcripts that aren't available.

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 broadcast_id parameter is fully documented in the schema, including its origin from search_results. The description's mention of the same origin adds no new semantic detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('full transcript of an imported Twitter Space') and scopes it by broadcast_id. It is clearly distinguishable from siblings like list_transcribed_spaces (enumeration) and search_results (ID source).

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

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

Explicitly ties the call to the broadcast_id sourced from search_results, giving the agent a clear precondition and sequencing cue. It does not, however, name alternatives or state when not to use it (e.g., for non-imported Spaces).

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

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

Annotations already establish that this is a read-only, non-open-world call. The description adds useful behavioral context: the data comes from AlphaGrowth, investments are newest first, and results are paginated at 50 per page. It does not discuss error handling or rate limits, but it goes meaningfully beyond the annotations.

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

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

The description is two compact sentences with the core resource stated first and useful return/pagination context second. It contains 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?

With no output schema, the description usefully lists the profile fields and explains investment ordering and page size. It is sufficient for an agent to call the tool correctly, though it does not describe invalid-slug or empty-result behavior.

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

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

Schema description coverage is 100%, and both parameters are well documented in the schema. The description echoes the page size but does not add new meaning about slug format or page behavior beyond what the schema already provides.

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

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

The description states a specific resource and scope: a crypto investor's public profile plus its investments, including the profile fields available. It is clearly not a generic list, though it does not explicitly distinguish itself from siblings such as top_investors.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives like top_investors or recent_funding_rounds. The slug schema hints at those alternatives, but that guidance is in the schema rather than the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value by describing the shape of each returned record (id, search text, active flag, last-searched time, result count), which annotations cannot convey. It doesn't say whether the list is paginated or bounded, a minor remaining gap.

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

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

Three short sentences, zero filler: what it lists, what each record contains, and how to use the ids. The core purpose is front-loaded in the first clause, so skimming yields the essential 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 correctly shoulders the burden of explaining return values, which it does field by field. The only omission is any note on result volume or pagination, which for a keyword tracker list is likely minor but not stated.

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 is 4; there is nothing for the description to compensate for. Coverage is moot here and the schema is closed with additionalProperties=false.

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 keywords whose results are tracked') and immediately enumerates the returned fields, so the agent knows exactly what this list contains. It is clearly distinguishable from siblings like search_results or list_sources, which return different entities.

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 final sentence gives an explicit downstream handoff: take an id from here and pass it as `keyword_id` to search_results, which makes the use case concrete. It does not state when NOT to use it or name a competing tool for listing keywords, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that these values feed search_results, but does not say whether the list is static or dynamic (i.e., whether a source can disappear if it stops producing results) or how large it typically is. Useful but not rich behavioral context.

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 waste. The what (sources) comes first, the concrete examples anchor it, and the consumption instruction closes it out.

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 burden of conveying return values, and the three examples do that well. The only remaining gap is whether the list is exhaustive/stable or reflects only sources currently producing results — a minor omission for a very simple 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?

The tool takes zero parameters, so the schema baseline is 4. The description goes slightly beyond by explaining what the returned tokens mean and where they are consumed, which is the relevant semantic information for a parameterless tool.

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?

Identifies the resource precisely ('sources that have produced results') and immediately grounds it with concrete example values (twitter_spaces, tweets_en, tweets_ja), which makes the unit of the list unambiguous. It is clearly distinguishable from siblings like search_results, though the verb is implied 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?

Explicitly tells the agent what to do with the output: 'Use one as the `source` argument of search_results.' This is a real routing instruction to a named sibling. It lacks any when-not guidance, but for a zero-parameter enumeration tool there is little alternative to exclude.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavioral context by disclosing the transcript-import precondition and describing what each entry contains (keywords that found it), which matters because there is no output schema. It stops short of noting pagination or result ordering for the default limit of 25.

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 with no filler, and the return shape plus the get_transcript handoff are both front-loaded. The first sentence's grammatical construction ('Twitter Spaces among the matching results whose import produced a transcript') is denser than needed but not 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?

For a four-parameter, optional-input list tool with no output schema, the description covers purpose, entry shape, and next step adequately. The remaining gap is what the 'matching results' base set actually is (imported data scope) and whether the limit paginates or is a hard cap.

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 every parameter including the search_in enum is already documented; the baseline is 3. The 'same filters as search_results' note adds some semantic framing but no detail beyond what the schema states, and it depends on the agent knowing that sibling.

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 specific resource (Twitter Spaces broadcasts whose import produced a transcript) and the return shape (one entry per broadcast, with the keywords that matched). It is distinguishable from search_results and get_transcript, though the opening clause 'among the matching results' is slightly tangled and leaves the base result set implicit.

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

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

It states the purpose in workflow terms: 'Use it to find transcripts worth fetching with get_transcript', pairing this discovery step with the explicit follow-up tool. It also tells the agent that it 'takes the same filters as search_results', giving a concrete mental model for the parameter set.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds useful context beyond that: a 90-day history ceiling, daily granularity, and free data provenance from AlphaGrowth. It does not discuss rate limits, response shape, or what happens for projects with no community data.

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

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

Two sentences, front-loaded with what the data is before the provenance footer. Both earn their place, though the AlphaGrowth attribution is marginally less essential than the metric description.

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 detailing returns, the description carries the burden of explaining the return values — and it does, specifying per-network follower/member counts, percent changes over three windows, and one point per day. Only the exact response field structure and large-slug handling are left unstated.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents slug, days, and network. The description reinforces the network list and the 90-day maximum, but adds no syntax, defaults, or edge-case behavior beyond the schema.

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

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

The description names the resource precisely — community growth for a crypto project — and enumerates the networks and metrics returned (followers/members, 1d/7d/30d percent changes). That distinguishes it from siblings like project_metrics and chain_metrics by scope. It never states an explicit verb, but the retrieval 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?

Usage is implied by the data described, and an agent can infer this is the right tool for community/social growth. However, there is no explicit when-to-use versus project_metrics or chain_metrics, and no mention that a slug must first be resolved via find_projects — that guidance lives only in the schema.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and closed-world scope are covered. The description adds genuinely useful context beyond that: chronological ordering (oldest first), which fields may be absent ('where known'), inclusion of a total, and provenance from a free third-party source (AlphaGrowth). It doesn't cover empty-result behavior or result size.

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 that leads with the resource and its scope, then the returned fields, then the data source. Every clause carries information. Minor cost: the parenthetical field list makes it dense to parse, 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 no output schema, the description steps in to describe the return shape (rounds with date/amount/type/valuation, investors, total raised), which is exactly what an agent needs. Missing only edge cases and a pointer to investor_profile for following up on the investor list.

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

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

Schema description coverage is 100% and the slug parameter even documents how to obtain the value ('find it with find_projects'), so the description adds nothing about parameters. Baseline 3 is appropriate when the schema carries the semantic load.

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 (a crypto project's funding rounds) and enumerates what it returns: date, amount, type, valuation, investors, total raised. The phrase 'a crypto project's' implies per-project scope, which differentiates it from the cross-project sibling recent_funding_rounds, though it never names that sibling to make the distinction 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?

Usage is only implied: the reader infers 'use this when you have a single project slug and want its full funding history.' It does not say when to prefer recent_funding_rounds or investor_profile, nor what happens for a project with no funding data. The schema partly compensates by pointing at find_projects for slug lookup.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully adds that the data is free from AlphaGrowth, indicating no cost/auth barrier, but says nothing about freshness guarantees, caching, or failure behavior for unknown slugs.

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 leads with the resource and then enumerates returned fields; the field list is long but each item conveys return-value content rather than padding.

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

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

With no output schema, the description carries the burden of describing returns and does so thoroughly via the field enumeration. For a read-only, one-parameter lookup the remaining gap is mainly the absence of usage routing to siblings.

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

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

Schema coverage is 100% and the single slug parameter is documented in-schema with an example and a pointer to find_projects. The description adds no parameter-level detail beyond what the schema already supplies, 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?

It clearly states the resource (a crypto project's metrics) and enumerates the fields returned (TVL, price, market cap, volume, revenue, users, social followers, plus description, categories, chains, links). The word 'project' implicitly separates it from chain_metrics, but no sibling is named explicitly.

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

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

The description offers no guidance on when to use this tool versus chain_metrics, rank_projects, or other siblings. The only routing hint ('find it with find_projects') lives in the schema, not the description.

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

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

Annotations already declare a safe read (readOnlyHint=true, openWorldHint=false), so the description only needs to add context. It does contribute two non-obvious traits: fixed 50-per-page pagination and the fact that sub-projects like Aave V2/V3 appear as separate rows beside their parent. It omits what a returned row actually 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 sentences, front-loaded with the core ranking behavior, then the sub-project caveat. The closing source attribution ("Free data from AlphaGrowth") is mildly promotional but does signal no-cost/no-auth access, so it roughly 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?

Five optional parameters and no output schema mean the agent must infer the response shape. The description never says what a ranked row includes (project name, slug, the sorted metric, changes), which is a meaningful gap for a list-producing 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 every parameter is already documented, including pagination, chain/category slugs and the sort enum. The description restates the metric families at a high level but adds no syntax or value details beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ("Ranks crypto projects") plus the metrics, optional scoping, and page size, which makes the tool's output shape imaginable. It notably does not contrast itself with the lookups (`find_projects`, `project_metrics`), so sibling differentiation is left implicit.

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

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

Usage is implied by "optionally within a category or chain" and "50 per page", which suggest exploratory ranked listing. There is no explicit when-to-use or when-not-to-use guidance and no mention of when to reach for `find_projects` or `project_metrics` instead.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context — newest-first ordering, 50 items per page, and data provenance (AlphaGrowth) — but says nothing about how deep the history goes or what happens at the page limit, which matters for a paged feed.

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 ordering, followed by returned fields and the optional filter. The source attribution is mild padding but defensible; nothing else 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?

For a read-only, two-parameter list tool with no output schema, the description is nearly sufficient because it enumerates the returned fields and the sort order. The remaining gap is pagination depth and where category slugs come from.

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, and '50 per page' / 'optionally within a category' merely restate them. No additional meaning such as valid category slug sources or paging strategy is contributed, 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 (crypto funding rounds) with ordering (newest first) and the fields returned (project, category, amount, type, investors). It implicitly separates itself from project_funding by being a global recent feed, but never names a sibling, so an agent must infer 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?

'Optionally within a category' signals the one filtering mode, so the usage is implied rather than stated. There is no explicit when-to-use-this vs project_funding or investor_profile guidance, and no note about when paging back through history is appropriate.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: deterministic newest-first ordering, the exact field set each row returns, a transcript-availability flag, and which value to forward to get_transcript.

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: ordering first, then filtering dimensions, then the return shape and handoff. No filler and nothing important is buried.

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 by enumerating row fields and the transcript flag. Paging is left to the schema's limit/offset descriptions, which is reasonable, though the absence of any note about total or result-set size keeps it just short of 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 all six parameters are already documented, and the description largely restates them ('filter by keyword, by source, and by free text'). It does sharpen the mental model of the search_in scope (titles, Twitter Space transcripts, or both) but adds no format, boundary, or interaction detail not already in the schema.

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

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

States a specific resource and scope ('Recorded search results, newest first') and makes clear this reads a stored history rather than performing a live search — a distinction not obvious from the name alone. It also names the downstream sibling get_transcript and the field (broadcast_id) that connects them, so an agent can place it in the workflow immediately.

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

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

The filtering dimensions (keyword, source, free text across titles/transcripts) imply when the tool is appropriate, and the get_transcript handoff hints at the next step. However, no sibling is named as an alternative and there is no explicit when-not guidance, e.g. that source values come from list_sources or keyword ids from list_keywords (that appears only in the schema).

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, closed-world safety profile, so the description's job is output shape — and it delivers: it discloses that each investor carries only the first 20 funded projects, that projects_more counts the remainder, and that pages hold 50 records. It omits data freshness and per-investor fields, but the added context is meaningful.

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 the resource and ranking first, then the output-shape caveats, then attribution. The nested parenthetical is dense but every clause carries information; 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?

With no output schema, the description must explain what comes back, and it covers ranking field, record count per page, and the truncation semantics via projects_more. What is still missing is the actual set of fields per investor (name, avatar, socials, amounts) and whether the top-100 boundary interacts with paging.

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

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

Schema coverage is 100%, and the description largely restates what the schema already says about page size and the two sort modes. The projects_more note adds value but relates to output, not to the two input parameters, so baseline 3 is right.

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: the top 100 crypto investors, ranked by projects funded or USD invested. An agent can immediately tell this is a leaderboard listing rather than a lookup. It does not explicitly name the nearest sibling (investor_profile), so differentiation is only implicit.

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

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

Usage is implied — this is the browsing/ranking tool — but the description never says when to use it over investor_profile or project_funding, nor any prerequisites. No exclusions or alternatives 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?

Annotations already cover the read-only, closed-world safety profile, and the description adds genuinely non-obvious behavior: 50 companies per page and, critically, that totals aggregate across every company rather than the current page. The data source and 'free data' note add provenance an agent could not infer 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?

One dense sentence plus a short provenance clause; the resource definition is front-loaded and nothing is buried. The AlphaGrowth attribution is marginal but small enough not to count as bloat.

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

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

For a no-required-parameter, read-only list tool with no output schema, the description supplies what is returned, the page size, and the important caveat that totals are global. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and the single page parameter is fully documented there, so the schema carries the load; the description's '50 per page' merely restates the schema and offers no extra paging semantics such as max page or out-of-range behavior.

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 with concrete scope: public companies holding crypto on their balance sheet, plus the exact metrics returned (market cap, NAV, mNAV, holdings per token). It implicitly separates itself from the DAO-treasury siblings by emphasizing 'public companies,' though it never names those siblings explicitly.

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

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

Usage is only implied – an agent can infer this is the lookup for corporate crypto treasuries, but the description gives no explicit when-to-use or when-not-to-use guidance, and does not route to dao_treasuries or chain_metrics for the adjacent questions those tools answer.

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