EventTrader Research (read-only)

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

Beyond the readOnly/idempotent annotations, the description adds meaningful behavioral context: it answers from live measured returns and real backtests rather than promises, it shares the same answer as a listed endpoint, and it has a defined confidence threshold below which it would rather not guess. This is rich behavioral disclosure.

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 with no filler: the first states purpose and scope with examples, the second gives an endpoint equivalence, and the third covers confidence behavior and the alternative. Each sentence earns its place and the key 'no key needed' constraint is front-loaded.

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

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

The description is adequate for a simple question-answer tool: it covers auth needs, scope, and confidence behavior, and the schema fully documents parameters. The only gap is that with no output schema, the exact response shape is not described, though 'Same answer' implies the content type is an answer.

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

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

The input schema already documents both parameters fully (question and optional session_id), and the schema description coverage is 100%. The description does not need to repeat parameter details; it adds context about question topics but no new parameter-level meaning beyond what the schema provides.

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

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

The description uses a specific verb ('Ask') and resource ('EventTrader's AI agent NEXUS'), and clearly scopes it to platform questions. It also distinguishes itself by noting 'no key needed' and references ask_nexus_deep as the deeper alternative, so an agent can tell it apart from siblings.

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

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

The description gives explicit use cases (returns, features, rules, registration, deposits, trading, cloning) and an explicit routing rule: when confidence is below 0.7 and an API key is available, use ask_nexus_deep for a full investigation. It also states that this tool needs no key, directly addressing the alternative.

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, so the description correctly aligns with them and adds extra context: 'no auth', the counting start date, and the exact time windows and metrics returned. This goes beyond the structured annotations without contradicting them.

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

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

Four sentences, each earning its place: purpose and motivation, with-path behavior, without-path behavior, and access/data caveats. It is front-loaded with the key purpose and 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?

For a read-only stats tool with no output schema, the description adequately explains both modes' return content, the time windows, the leaderboard ranking behavior, and the access constraints. Remaining details like limit and sort options are already covered in the input schema, so nothing critical 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?

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description usefully explains the path-dependent behavior and gives an example, but it adds little new meaning for days, sort, or limit beyond what the schema already states.

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: it returns public traffic and likes for rebuilt apps, with the explicit goal of measuring whether a rebuild is used. It also clearly distinguishes the two modes: per-app stats with 'path' vs a ranked leaderboard without 'path', so an agent knows exactly what outcome to expect.

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 contextual guidance: use 'path' to get a single app's stats and omit it for the ranked leaderboard. It does not explicitly compare against sibling tools like bb_search_rebuilt_apps, but the usage context is clear enough for an agent to know when this tool 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 destructiveHint=false, and the description reinforces this with 'Read-only, no auth'. It additionally provides value by stating the stage semantics and the lifecycle-dependent field ('our_url once shipped'), which is useful behavioral context beyond 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?

A single dense sentence that front-loads the core operation and then packs essential response details. Every clause adds information, with no redundancy or filler.

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

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

For a single-parameter read-only tool with rich annotations and no output schema, the description fully covers what the tool reads, the input needed, the auth requirement, and the read-only nature. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% and the schema already documents the 'ticket' parameter with an example. The description adds no further parameter detail beyond implying that the ticket identifies the build to read, 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?

States a specific verb and resource: 'read one build', and enumerates exactly what is returned (stage, scope, elapsed time, our_url, message log). It is clearly distinguishable from sibling search tools like bb_search_rebuilt_apps and mutation tools like bb_request_change.

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

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

The description clearly implies the tool is for retrieving a single existing build by ticket. It does not explicitly name alternatives or exclusion conditions, but the singular 'read one build' plus the required 'ticket' parameter provides clear usage context.

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=false, and destructive=false. The description adds useful 'no auth' information and clarifies that the tool searches the /tools directory. Repeating 'Read-only' is redundant but not harmful.

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

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

The description is compact and front-loaded: it states the purpose, the trigger, the fallback action, and access requirements in three short sentences. No wasted words.

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

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

For a single-parameter read-only lookup with no output schema, the description conveys purpose, trigger, and scope. It doesn't spell out the return format, but 'check whether' plus the filing workflow makes the expected result reasonably clear. Minor gap only.

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 query parameter is already well described with examples ('app name, e.g. a screener or charting tool'). The description adds little beyond that, but the schema carries the meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb-resource pairing: 'check whether EventTrader already has a page for a financial app (the /tools directory)'. It clearly scopes the tool to the Build it Better workflow and distinguishes it from generic search tools among the siblings.

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

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

It explicitly says 'Call this before filing' and explains that an app already present can still be filed by sending improvements, which gives a clear trigger and subsequent action. It does not name specific alternative tools or list when not to use it, but the workflow guidance is solid.

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; the description adds meaningful behavioral detail beyond this: auction ordering rules, equal-bid tie-breaking, no-bid fallback order, and the fact that bids are in ET10 and never collected. There is no contradiction with 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 five short sentences with no filler. It front-loads what the tool is, explains ordering mechanics, notes the bid currency and non-collection, lists return values, and states auth requirements. Every sentence adds useful information.

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

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

For a zero-parameter, read-only, no-auth tool, the description is complete: it explains the resource, auction rules, return shape, and access requirements. There is no output schema, but the description explicitly says the tool returns each startup's position, name, bid, and rules, which is 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?

The tool has zero parameters and schema description coverage is 100%, so the baseline is 4. The description cannot add parameter meaning, but it compensates by stating the return contents and behavioral rules, which is the only 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?

The description names a specific resource ('public line for Turn your App into a Startup'), characterizes it as an auction, and states what it returns (position, name, bid, rules). This distinguishes it from bidding-oriented siblings like bb_startup_bid and feature_place_bid by focusing on the public line/queue view.

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

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

The description gives clear context: it is public, read-only, requires no auth, and returns line positions and rules. It does not explicitly name alternative tools or say when not to use it, but the usage context is clear enough that an agent can infer it is the correct choice for viewing the startup line.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the response bundles replication log and edit history, but it does not disclose further behavioral details such as error cases or relationship to replication/revise workflows.

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 packs the action, resource, and return scope with zero filler. Every word earns its place.

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

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

For a one-parameter read-only tool with strong annotations, the description is nearly complete: it states the resource and the bundled response data. The absence of an output schema makes the exact shape of the replication log and edit history unspecified, but that is not required to select or invoke the tool correctly.

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

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

The only parameter, post_id, is fully described in the schema as a required string 'Post id' (100% schema coverage). The description adds no additional meaning beyond implying the post identifier is the target of the read.

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

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

The description uses a specific verb ('Read') and a specific resource ('one Returns Board post'), and adds the return scope ('with its replication log and edit history'). This clearly distinguishes it from the sibling board_read_thread tool and from board_post/board_revise write 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?

No guidance is given for when to use this tool versus board_read_thread or board_search, and no exclusions or prerequisites are stated. An agent must infer from the name and sibling list that this is for reading a single post.

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

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

Annotations already establish read-only/idempotent/non-destructive behavior. The description adds useful behavioral detail: it returns the complete thread with all versions/notes/replications in order, which an agent would not infer from schema alone. No contradiction.

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

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

Single focused sentence, front-loaded with the action and resource, with no filler. Every word contributes to understanding what the tool does.

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

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

For a single-parameter read with strong annotations, the description sufficiently covers what is returned. It does not specify ordering semantics or the exact shape of a thread, but these are minor for correct invocation.

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

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

Schema covers the only parameter 100%, including a concrete example, so the description has no obligation to add syntax. It adds no thread_key specifics 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 identifies the exact operation — 'Read one Returns Board thread in full' — and elaborates scope with versions/notes/replications. It is specific enough to distinguish from board_read_post or board_search, though it does not explicitly name a sibling.

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 phrasing implies use when retrieving the full history of a single thread, and the sibling set includes narrower lookup tools like board_read_post, but the description gives no explicit when-to-use vs alternatives or exclusions.

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, so the safety profile is covered. The description adds useful behavior—ordering by newest activity and selecting the best-ranked post as head—but does not describe pagination, response shape, or filter interpretation.

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

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

The description is compact and front-loaded, containing no filler. However, the 'List Returns' wording is awkward and mildly confusing, which keeps it from being a model of crisp structure.

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

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

For a simple read-only listing tool with rich annotations and fully described schema parameters, this is minimally adequate. Gaps remain: no output schema or return-shape detail, no accepted status values, no pagination behavior, and no guidance about when this tool is preferable to sibling board tools.

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

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

The input schema has 100% coverage, documenting all four optional parameters with at least minimal descriptions. The tool description adds no extra meaning about accepted status values, default limits, or how channel and status interact.

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 ('Board threads') and the action ('List/Returns'), and adds distinguishing details: newest activity first and each thread's best-ranked post as head. It is clear enough to separate this from single-thread readers, though the ungrammatical 'List Returns' phrase prevents a perfect score.

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

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

No when-to-use guidance or explicit alternatives are provided. An agent must infer this is the listing counterpart to board_read_thread and must guess when to prefer it over board_search or board_channels.

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, covering the safety profile. The description adds value by specifying the output structure (concept hierarchy with action links) but does not disclose potential limits, pagination, or ordering. It adds moderate 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 description is two sentences with no redundant wording. The core purpose and scoping are front-loaded, followed by the return format. Every word contributes to the tool's understanding.

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

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

For a simple read-only browse tool with one optional parameter and no output schema, the description provides sufficient information for an agent to know what to expect. It names the return structure and the scoping mechanism. Minor omissions like pagination or result limits are not critical for a taxonomy browse, so the description is nearly 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% (the sole parameter has a description: 'Optional dimension slug to scope to'). The description echoes this scoping concept but adds no new parameter-specific details, such as how to obtain a valid slug or constraints on the slug format. Since coverage is high, baseline 3 is appropriate.

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

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

The description clearly states the verb 'browse', the resource 'master ontology taxonomy tree', and the optional dimension scoping. It also describes the return value as a concept hierarchy with action links, distinguishing it from siblings like search_ontology and resolve_ontology_concept, which have different verbs and purposes.

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

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

There is no guidance on when to use this tool versus alternatives. The description mentions optional scoping but does not explain when to browse versus search or resolve concepts, nor does it reference sibling tools. An agent would have to infer usage context from the name and description 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?

Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, the description goes far beyond that. It discloses that each record includes nine dimensions, weighted totals, evidence-backed penalties, cited source URLs, and metadata, and it even provides the exact scoring formula per rubric version. This is rich behavioral context that lets an agent understand what the tool returns and how scores are constructed, with no contradiction of 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 extremely long and densely packed, with extensive detail about six research dimensions, weighting formulas, and rubric versions (v2/v3/v4). While this detail is informative, it is not concise for a tool description; the key behavior (returns list or single person) is embedded in a wall of text. It is front-loaded with the index definition but quickly becomes over-specified.

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 explaining return values, and it does so comprehensively: it describes the ranked list, per-person records, nine dimensions, penalties, source URLs, and the verification formula. It is nearly complete, but some variables in the formula (e.g., H and I) are not explicitly defined, and the claim that 'popularity, fundraising and media coverage carry zero' versus the formula's use of H+I+SF creates slight ambiguity for an agent trying to re-verify scores.

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

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

The input schema already has 100% coverage, with descriptions for both 'slug' and 'limit'. The description adds a little extra meaning for 'slug' by indicating that omitting it returns the whole list and including it returns one person, but it provides no additional semantics for 'limit'. This matches the baseline of 3 for high schema 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?

The description clearly states that this tool returns a ranked list of founders and CEOs based on an AI expertise index (0-100), or a single person when a slug is provided. It names a specific resource (the CEO AI Expertise Index) and its distinguishing action ('Returns the full ranked list, or one person with ?slug='), which differentiates it from the many other get_* 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?

There is no explicit guidance on when to choose this tool over alternatives. It does explain the two invocation modes (omit slug for the full list, include slug for one person), but this is parameter usage rather than use-case guidance. No sibling tool is mentioned or contrasted, so an agent is left to infer when this index is the right resource.

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 the description adds non-obvious behavior: the per-row return shape (score, band, counted patterns, coverage note) and status codes such as no_pool, no_candles, too_little_history, collecting. It also notes no API key is needed and points to chart_analyzer_study for the methodology.

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

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

Dense but front-loaded: the batch scope and item forms come first, then the gem_screener alternative, then output behavior. The closing 'Not financial advice' is boilerplate that does not earn its place, but overall there is little 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 description compensates by summarizing row fields and no-score statuses, plus noting the 300-item cap and the study reference for pattern rates. An agent has everything needed to invoke and interpret this batch tool correctly.

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

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

Schema coverage is 100%, so a 3 is the baseline, but the description adds real meaning: items accepts either {contract, chain} or {symbol} forms, all rows use one timeframe, and gem_screener replaces items entirely. That clarifies how the parameters interact beyond the schema text.

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

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

States a specific verb and resource with scope: 'Score many charts in one call (up to 300)'. It is clearly the batch counterpart to chart_analyzer_score and also covers the gem_screener mode, so an agent can distinguish it from siblings without opening schemas.

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

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

Explains the two selection modes (items list vs gem_screener=true) and the 'many in one call' context that selects batch over single scoring. It does not explicitly name chart_analyzer_score as the alternative for one-off lookups, leaving that inference to the agent.

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/openWorld=false, so the safety profile is covered; the description adds real value on top by explaining the score's anchor (50 = the study base rate), the coverage.note caveat about coins/timeframes the study misses, and 'read-only, no key, not financial advice'. It does not discuss latency, rate limits, or failure modes.

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?

Purpose and scale are front-loaded, and nearly every clause carries information (scale, patterns, input modes, caveats). It is dense and runs several ideas together with em-dashes, which slightly hurts scanability, but there is little 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, 7 optional parameters, and no required fields, the description does a good job of describing what comes back (score, patterns tagged by measured success rate, drawing points, coverage note). The only thin spot is that the precise return shape of drawing points and coverage is left implicit, but it is adequate for calling the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: candles may be an array OR CSV text of 60-5000 rows, chain is only needed when the address is ambiguous, symbol maps to Binance USDT pairs, and shared tickers are never conflated. This genuinely reduces ambiguity about how to supply inputs.

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

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

States a concrete verb+resource (score a chart) and pins down the scale (1 = very bearish, 100 = very bullish) plus the outputs (patterns, drawing points). It enumerates the patterns detected and names the sibling chart_analyzer_study for methodology, so an agent can separate it from chart_analyzer_batch and the crypto_* analytic 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?

Gives clear input-mode routing: contract (+ chain when the address alone is ambiguous) OR symbol OR candles, with the conditions for each spelled out. It does not, however, state when to prefer this tool over chart_analyzer_batch or crypto_outlook, so it is context-rich but not exclusionary.

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 auth context ('no key'), a disclaimer ('Not financial advice'), and a content sketch of what the study exposes - modest value, but no pagination, size, or freshness details.

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

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

The content list is front-loaded and dense but somewhat sprawling, mixing the study's contents, a source attribution, a self-referential pointer, and a disclaimer. The '(see chart_analyzer_study)' aside is noise that repeats the tool name.

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

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

With no output schema and no parameters, the burden falls on the description, and it does enumerate the study's main dimensions (universe, train/held-out periods, per-pattern sample size and success rate, insufficient-sample flags, held-out outcome). An agent knows what it will receive, though formatting and volume are unspecified.

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

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

The tool takes zero parameters and schema coverage is 100%, so the baseline of 4 applies. There are no parameter semantics for the description to clarify.

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 methodology/study behind the Chart Analyzer score - and enumerates its contents (universe, periods, sample sizes, success rates, held-out result). It implicitly distinguishes itself from the sibling chart_analyzer_score by being the underlying evidence rather than the score itself, though it never names that sibling directly.

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 tool is for inspecting the study/methodology backing the score, but there is no explicit when-to-use or when-not guidance, and no named alternative. The self-referential parenthetical '(see chart_analyzer_study)' adds no routing value.

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, but the description adds real behavioral context beyond them: no API key required, every number carries source and time, implausible numbers are withheld rather than guessed, and no orders/funds are touched. These are useful disclosures for a data-reference tool.

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

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

The enumeration is front-loaded and useful, but the tail is padded with promotional and legal boilerplate ('Places no orders, moves no funds', 'Not financial advice') that doesn't help an agent select or invoke the tool. It reads as one dense paragraph rather than a tight, purpose-built definition.

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 reference tool with no output schema, the description covers what the tool returns (the alert kinds, their check cadence, and delivery) thoroughly enough to call it correctly. Missing only explicit routing guidance relative to the sibling alert tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter details are needed or missing.

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

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

The description clearly states the resource: the categories of alerts the system can send about a coin, enumerating them (price above/below, 24h/7d change, market cap, volume, Animal Spirits, buzz). An agent can tell this is a reference/enumeration tool, distinct from crypto_alert_create or crypto_alerts_list. It stops short of explicitly contrasting with those siblings by name.

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

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

There is no explicit when-to-use guidance — nothing says to consult this before calling crypto_alert_create to learn valid alert kinds, nor any exclusion. Usage is only implied by the enumeration of alert types.

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 safety (readOnly/idempotent/non-destructive/non-open-world), and the description adds genuinely non-obvious behavior: every number carries its source and time, values failing a plausibility check are withheld rather than guessed, and polling is the intended retrieval model. The API-key requirement is also disclosed.

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?

Purpose and scope are front-loaded and most clauses carry real information. There is some filler (the dashboard attribution link, "Not financial advice", and the no-orders/no-funds sentence that partly restates annotations), which keeps it from being tight.

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

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

With no output schema, the description enumerates the returned fields, ordering, and the withholding rule, so an agent knows what it will receive. Parameters, prerequisites, and side-effect profile are all covered.

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; the description goes further by explaining the cursor pattern ("Pass after_id = the last id you saw to get only new ones"), which tells the agent how to use the parameter rather than just what it filters. The limit parameter is left entirely to the schema.

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

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

States a specific resource ("the alerts that fired for your agent") with ordering ("oldest first") and the exact payload fields (what crossed, value, price, Animal Spirits reading, coin page). The "for your agent" scope plus the incremental-cursor framing cleanly separates it from the sibling crypto_alerts_list / crypto_alert_create / crypto_alert_kinds.

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?

"Poll this when you have no webhook" gives an explicit trigger condition, and "Needs a registered agent (API key)" states a prerequisite. It does not, however, name or contrast with the sibling listing tool (crypto_alerts_list), so the alternative-selection guidance is only partial.

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/non-openWorld, but the description adds genuine behavioral context: the API-key auth requirement and the data-quality rule that implausible numbers are withheld rather than guessed. 'Places no orders, moves no funds' leans redundant with the annotations, but the auth and plausibility behaviors are new information.

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?

Purpose is front-loaded effectively in the first sentence, but the tail is padded with promotional/contextual filler ('From EventTrader's crypto dashboards (cymetica.com/crypto)', 'Not financial advice') and safety lines that largely restate the annotations. Tightening would improve signal.

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 and no output schema, the description usefully sketches the return content (per-alert fire counts, source and timestamp per number) and flags the auth requirement. It is nearly complete, missing only an explicit note on the shape/ordering of the returned 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level detail is needed here.

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 alerts your agent has set, with how often each has fired,' which cleanly places it as the read/list counterpart to crypto_alert_create and crypto_alert_delete. It stops short of explicitly naming a sibling it is not (e.g., crypto_alerts_inbox), so an agent must infer the boundary from the 'your agent has set' phrasing.

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?

Provides a real prerequisite ('Needs a registered agent (API key)') that determines applicability, but gives no when-to-use/when-not guidance and never routes the agent to crypto_alerts_inbox or crypto_alert_create. Usage is implied rather than stated.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: no API key, no orders, no fund movement, plausibility-checked numbers are withheld rather than guessed, and every number carries source and time. This is substantive context beyond the structured fields.

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

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

Front-loaded with the core measurement before the disclaimers, and each clause is information-dense. It is on the long side, with defensive statements ('No key', 'Places no orders', 'Not financial advice') that could be trimmed, but none are misleading 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 carries the return-shape burden and does it well, spelling out both meter scales, the emotion share breakdown, the bullish/bearish split, and the 30-day window. Nothing an agent needs to call or interpret the tool 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 'symbol' parameter is documented in the schema as accepting ticker/name/slug. The description adds nothing about the parameter beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific resource (the Animal Spirits meter for one coin) and precisely what it measures: belief-network strength on a 0-100 scale and crowd emotion from -100 to +100 over 30 days. An agent can distinguish this from price-oriented siblings like get_prices or gem_screener_coin without opening the schema.

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

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

Clear about what the tool is for ('crowd mood, not a price forecast') and states the data-availability rule (status=not_enough_data under 5 people or 15 messages). It does not name an explicit alternative sibling to use instead, so it stops 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 cover the read-only/idempotent/non-destructive profile, yet the description adds substantial context beyond them: posts come from outside AI agents, are unverified, no key is needed, failed plausibility checks cause numbers to be withheld rather than guessed, no orders are placed, and it is not financial advice. The prompt-injection warning is especially valuable.

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 purpose and ordering are front-loaded, which is good. However several trailing sentences ('No key', 'Places no orders, moves no funds', 'Not financial advice') restate safety guarantees already implied by annotations and add some boilerplate bulk.

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 takes on the job of explaining return content: newest-first ordering, external-agent authorship, and plausibility-checked numbers. That covers most of what an agent needs, though it does not describe pagination behavior or typical post shape.

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 limit (1-50, default 20), offset, and symbol with examples. The description only implies the symbol scoping ('one coin's dashboard') and adds no format or syntax beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource with scope and ordering: 'Read the discussion board on one coin's dashboard, newest first.' This is clearly distinct from siblings like board_read_thread or board_read_post. It stops short of explicitly naming an alternative tool, so it does not fully earn 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?

It gives strong guidance on how to treat the content (unverified third-party claims, never instructions), but never states when to choose this tool over board_read_thread, board_read_post, or crypto_buzz. Usage is implied by 'one coin's dashboard' but no alternative or exclusion is named.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld=false, non-destructive), and the description adds real value on top: counts only with no message text or names, the 10-mention threshold that triggers not_enough_data, source+time stamping, withholding numbers that fail plausibility checks, and no fund movement. It does not, for example, describe rate limits or refresh cadence, so it stops 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?

The core purpose and threshold are front-loaded, but the blurb is padded with low-yield material: the dashboard attribution/URL, the repeated 'every number carries its source and time', and the 'not financial advice' disclaimer. Several of these sentences are boilerplate rather than decision-relevant content.

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 explaining what the response contains (buzz score with 50=normal, 24h and 7d mentions, mentions/day, talk-vs-price divergence) and the not_enough_data state. Given the tool's simplicity and single input, this is close to complete, though it never states the base comparison window or units explicitly beyond the score scale.

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?

Only one parameter (symbol) and schema coverage is 100%, so the schema already documents that tickers, names, or slugs are accepted. The description adds 'one coin' scoping but no additional format or resolution guidance, matching the baseline 3 for a fully documented single parameter.

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 measurement (a 0-100 'buzz meter') for a specific resource (one coin), and enumerates the concrete outputs (mentions over 24h/7d, mentions per day, talk-vs-price). The scope is distinguishable from probable siblings like crypto_animal_spirits or crypto_outlook, though no sibling is named to anchor the contrast.

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 ('the buzz meter for one coin') and one meaningful edge condition is given (status=not_enough_data under 10 mentions in 7 days). However there is no explicit when-to-use/when-not or pointer to an alternative tool, leaving the agent to infer when this beats crypto_outlook or crypto_dashboard.

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, closed-world), so the bar is lower. The description still adds real behavior: plausibility-checked numbers are withheld rather than guessed, every value carries source and time, and it explicitly states no orders are placed and no funds move.

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

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

Front-loaded with the resource and its contents, but the middle is an undifferentiated run-on list of a dozen-plus fields. The operationally important clauses (building status, withheld numbers, no orders) are buried at the tail and would be better surfaced earlier.

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 enumerates the return payload and the source/time provenance rule, which is exactly what an agent needs. It is complete enough to call correctly; only sibling differentiation 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 schema already documents the sole symbol parameter (ticker, name, or dashboard slug with examples). The description adds only the edge-case that an unbuilt coin is still accepted, which is marginal semantics beyond the schema; 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?

Opens with a specific verb+resource framing ('One coin's dashboard: price, 24h/7d/30d change, market cap...') that tells an agent exactly which coin it is fetching and what comes back. The enumerated contents clearly separate this from siblings like crypto_dashboard_search (discovery) and nightly field tools like crypto_animal_spirits.

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 one concrete usage rule - a not-yet-built coin begins building and returns status=building, so call again in a minute - which is genuinely useful. However, it never states when to prefer this over crypto_dashboard_search or the other per-coin tools, leaving tool selection 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?

Beyond the readOnly/idempotent annotations, it discloses auth requirements and their exact mechanisms, the user-facing URL, and the data-integrity guarantee that every number carries a source/time and failed plausibility checks are withheld rather than guessed. It also adds the negative constraints 'places no orders, moves no funds.'

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

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

The core behavior, no-symbol mode, and auth path are front-loaded and information-dense. It runs long and tacks on trailing boilerplate ('Places no orders... Not financial advice'), which slightly dilutes the payload.

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 naming the fields returned (sections, ordering, pinned numbers, price lines with distance-from-now, notes, heading). It omits pagination/size details, but for a single-coin read it is otherwise complete.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema ('coin ticker, name or dashboard slug'). The description largely restates this behavior ('all of the user's versions when left out') without adding format examples or edge cases, 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 concrete verb and resource ('Read your user's own version of one coin's dashboard') and enumerates the sub-resources returned (sections, order, pinned numbers, price lines, notes, heading). This clearly distinguishes it from the plain crypto_dashboard and the write-oriented crypto_dashboard_customize sibling.

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

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

Explains the two usage modes ('With no symbol: every field you can change... and the coins your user has a version of') and gives explicit prerequisites for linking an agent (API key, OAuth, or claim POST). It lacks an explicit 'use X instead of Y' routing statement against the sibling dashboard tools, keeping it at a strong 4.

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

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

Goes well beyond the readOnly/idempotent annotations: it discloses that dashboards may be lazily built on first request, that a no-key call is allowed, that every number carries a source and time, and that numbers failing a plausibility check are withheld rather than guessed. These are non-obvious behaviors an agent cannot get from 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?

Purpose is front-loaded in the first sentence and the result/fallback behavior is efficiently explained. The trailing disclaimers ('No key', 'Not financial advice', 'Places no orders') are padding that dilutes an otherwise tight 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, the description carries the return burden and does describe the readiness field and the next_actions fallback, so an agent knows what to expect. It stops short of naming exact result fields, which is a minor gap for a one-parameter lookup 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 single 'query' parameter is fully documented in the schema (100% coverage), and the description only repeats 'by ticker or name' without adding format, delimiter, or ambiguity-resolution guidance. Baseline 3 is appropriate when the schema carries the 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 specific verb and resource (find a coin's dashboard) plus the lookup key (ticker or name), which is easy to distinguish from the sibling crypto_dashboard retriever. Sibling differentiation is only implicit, however, and the description never names alternatives.

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 explains what happens on a match (readiness flag) and on a miss (next_actions suggests alternatives), which implies discovery-first usage. But it never states an explicit when-to-use condition or contrasts itself with crypto_dashboard or search_markets.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the bar is lower, yet the description still adds genuine context: no API key needed, no orders placed and no funds moved, numbers that fail a plausibility check are withheld rather than guessed, and every number carries a source and timestamp. The no_simulation status case is a useful disclosed failure mode. It stops short of describing pagination or latency behavior.

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

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

The scope, percentile definitions, and the critical 'quote the range, never a single target' instruction are all front-loaded in the first two sentences. The remaining clauses are short and each carries an operational fact rather than filler, though 'From EventTrader's crypto dashboards (cymetica.com/crypto)' and 'Not financial advice' are more provenance branding than actionable content.

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 explain the return shape, and it does: percentile bands for six horizons plus the below-current-price path share, with a named degraded status. Combined with annotations covering safety, an agent has enough to call and interpret it, with the unresolved sibling overlap as the main gap.

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

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

Schema description coverage is 100%, so both parameters are already documented with their accepted values (1mo through 5y, omitted meaning all). The description's mention of the six horizons and the 5th/middle/95th percentile definitions adds framing but no new per-parameter syntax beyond what the schema provides. 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 first sentence states a specific verb-and-resource: it returns the simulated price range for one coin across six horizons, plus the share of paths ending below today's price. That is far more specific than the name alone. However, it does not distinguish itself from the sibling get_crypto_outlook, which by name looks like the same capability, so an agent has no basis for choosing between them.

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

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

It gives real usage constraints: quote the range rather than a single target, treat results as scenario simulations rather than forecasts, and expect status=no_simulation when the price history cannot be proven to belong to this coin. But it never says when to reach for this tool instead of the near-identical sibling get_crypto_outlook or the other crypto_* tools, so routing guidance is implied at best.

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 readOnly/idempotent/non-destructive/closed-world, but the description adds real value: no API key needed, every number carries source and timestamp, and implausible numbers are withheld rather than guessed. It also clarifies it places no orders and moves no funds, which is useful reassurance beyond the readOnlyHint.

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

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

The core behavior is front-loaded well, but the tail contains generic boilerplate ('Places no orders, moves no funds', 'Not financial advice') that consumes space without aiding tool selection.

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

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

For a single-param read tool with no output schema, the description covers what is returned, the ordering logic, and data-quality caveats. The main omission is guidance on when to prefer it over adjacent crypto 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?

With one parameter at 100% schema coverage, the schema already documents that symbol accepts a ticker, name, or dashboard slug with examples. The description adds nothing about the parameter, 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: up to five coins related to one coin, ordered by co-mention then category. This is unmistakably distinct from siblings like crypto_dashboard or gem_screener_coin.

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

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

The description explains the ranking logic (co-named first, then same-category) and notes 'No key', which implies free/available usage, but it never says when to reach for this over crypto_dashboard, browse_ontology, or crypto_buzz. Usage is implied rather than routed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral detail: 'Read-only, no auth' and 'No dollars are required.' It also discloses the ranking logic and the specific return payload, going beyond the annotation baseline without contradicting it.

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

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

The description is compact and front-loaded with the core topic, then explains the mechanism, then enumerates return values. Every sentence adds useful information, with no filler or repetition of schema details.

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 and no output schema, the description carries the full burden of explaining what the agent will get back, and it does: rules wording, smallest first bid in ET10, dollar worth, and the ET10 price. It also covers access requirements and cost, making it complete enough to invoke correctly.

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

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

The tool has zero parameters and the schema is empty, so there are no parameter semantics for the description to clarify. The description appropriately focuses on output and behavior instead, making the baseline score of 4 correct.

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 topic ('Feature Leaderboard: how bidding works') and lists the exact return values: rules wording, smallest first bid in ET10 and its dollar worth, and the ET10 price. It also distinguishes itself from sibling bidding tools by explicitly noting it is read-only, requires no auth, and no dollars are required.

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

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

The description clearly conveys that this tool is for understanding how feature bidding works and what the leaderboard ranks by, which gives a clear usage context. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by stating 'no auth' and revealing the privacy boundary: it never exposes who bid what. It also enumerates the exact subset of bidding data returned, going beyond what the annotations express.

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

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

Two compact sentences convey the tool's output fields, privacy boundary, and auth requirements without filler. The core scope, one feature's bidding numbers, is front-loaded, and every phrase contributes meaning.

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

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

For a one-parameter, read-only tool with no output schema, the description is complete: it lists every returned value, states the auth model, and relies on the already-comprehensive schema for input. No critical missing information prevents correct invocation.

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

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

The input schema has 100% description coverage and already explains feature_id as the feature's number from feature_board or its cymetica.com link. The description adds no new parameter-level detail beyond implying a single feature, 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 clearly specifies the resource: one feature's aggregate bidding numbers, including the ET10 bid, bidder count, highest bid, open status, and minimum. It also distinguishes itself by explicitly stating 'Never who bid what,' which separates it from per-bidder or per-account tools like feature_my_bids.

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 intended use is implied: call this when you need aggregate bidding numbers for a single feature. The 'Never who bid what' line warns against using it for bidder-level details, but no specific alternative tool is named and there are no explicit when-to-use or when-not-to-use conditions.

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 carry readOnly/idempotent/destructive safety, so the description earns credit for adding 'no auth' and the privacy guarantee that individual bidder identities are never revealed. It also discloses output shape (row fields and sort order), which is not in the schema. No contradiction with annotations.

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

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

Two compact sentences front-load the purpose and sort order, then enumerate output fields and constraints. No filler.

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

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

For a simple, one-parameter read-only tool with no output schema, the description covers scope, ordering, row fields, auth, and privacy. The only minor omission is stating 'returns a list' explicitly, but this is strongly implied by 'leaderboard' and 'each row.'

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 single parameter (limit) is fully documented in the schema (default 20, max 100), so the description carries no burden here. It doesn't add any usage nuance about the parameter, so baseline 3 is appropriate.

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

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

The description identifies the resource ('open features') and the exact output contract: ranking order ('most ET10 bid first, then votes') and per-row fields. It distinguishes itself from sibling tools like feature_bids/feature_my_bids by explicitly saying 'Never who bid what.' It lacks an imperative verb like 'lists', but the behavior is unmistakable.

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 'open features' scope plus 'Never who bid what' gives an agent clear context for when the leaderboard is appropriate and when a per-account bid detail tool would be needed. It doesn't name the alternative tools explicitly, so the routing instruction is implicit rather than explicit.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond annotations by explaining the account-link prerequisite and that commitment amounts are only relevant for features still open. This clarifies the data scope without contradicting 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?

Two compact sentences, front-loaded with the tool's purpose and followed by the key prerequisite. Every phrase carries information; there is no filler or redundant restatement of the title.

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

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

For a zero-parameter read-only tool with no output schema, the description adequately explains what the tool reports and what prerequisite must hold. It could go slightly further by describing the exact return shape, but the description is sufficient for an agent to know what this tool does and when to invoke it.

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

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

There are zero parameters, so the schema fully defines the input contract. The description adds useful context about what data is returned, compensating for the lack of an output schema. Baseline for zero-parameter tools is 4, and the description meets it.

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

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

The description clearly identifies the resource (the linked account's standing bids on features) and the scope (each feature, plus ET10 commitment on still-open features). This distinguishes it from siblings like feature_bids, which presumably shows broader bid data, by explicitly restricting to the linked account's own bids.

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

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

The description provides clear context on when the tool is applicable: it returns only the linked account's own bids and requires the agent to be linked to a platform account. It does not explicitly name alternatives or exclusions, but the scope is unambiguous enough for an agent to route to it correctly.

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 readOnlyHint, idempotentHint, and non-destructive status, so the bar is lower. The description goes beyond them by stating 'no auth' (an access requirement not in the annotations) and by describing what the thread contains, giving useful expectations about the response.

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 sentence plus a short trailing clause, front-loaded with the core purpose and with no filler. The 'EventTrader Feature Leaderboard:' prefix is marginally redundant branding but does orient the domain.

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

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

No output schema exists, so the description's enumeration of returned content (status, build plan, messages) is valuable and adequately covers the read. The only gap is pagination behavior for since_id, which would help callers traverse long threads.

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 feature_id and since_id both documented in the schema, so the description need not repeat them. It adds no meaning beyond the schema — notably no explanation of pagination semantics for since_id — 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 (read/thread retrieval) and resource (a feature's agent collaboration thread), and enumerates the payload: status, build plan, and messages. An agent can distinguish it from feature_thread_post 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?

Usage is implied rather than stated: the mention of 'every message' and 'Read-only' suggests this is the retrieval counterpart to the write tool, but no sibling (e.g., feature_thread_post, feature_board) is named and no condition for choosing this tool is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing the return content (venues, pipeline, route) and framing it as a 'concrete action plan', which goes beyond the annotations. It does not mention potential errors or prerequisites, but given the read-only nature, this is acceptable.

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

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

The description is a single, information-dense sentence with no filler. It front-loads the purpose ('Money-path resolver') and then enumerates the specific outputs, making it efficient and easily scannable. Every phrase contributes to the agent's understanding.

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

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

For a read-only tool with one parameter and no output schema, the description covers the essential information: what input is expected and what the output will contain (venues, pipeline, route). It does not specify the exact structure of the returned data, but the enumeration of components is sufficient for most agent use cases. A perfect score would require explicit mention of formatting or edge cases.

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 parameter 'instrument' is described as 'Instrument/asset concept slug'. The description rephrases this as 'instrument/asset concept' but adds no new meaning or format details. Baseline of 3 is appropriate since the schema already documents the parameter fully.

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

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

The description clearly states a specific verb (resolve) and resource (money-path/trade path) for an instrument/asset concept, and specifies the output: venues, execution pipeline, and place_order route. This distinguishes it from sibling tools like get_market or get_orderbook, which focus on market data rather than the full execution path.

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

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

The description implies when to use it ('given an instrument/asset concept, return...') but does not explicitly contrast with alternatives or state when not to use it. There is no mention of sibling tools like search_markets or get_market, leaving the agent to infer the appropriate context. It provides context but lacks exclusions or alternative routing.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world, but the description adds real context beyond them: data is collected every 6 hours and audited before publishing, null means unknown, every number carries {value, unit} and as_of, and it explicitly frames itself as 'a research screen, not a signal.' These freshness, null-semantics, and disclaimer disclosures are genuinely useful and not derivable from 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 a ~250-word run-on dominated by parenthetical field enumerations, with the actual task statement buried in the first clause and no paragraphing or bullet structure. Almost none of it is front-loaded and much of the field listing repeats information the payload itself would carry.

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 explaining returns, and it does enumerate the payoff fields, their shapes, and sources/freshness extensively. For an agent deciding whether to call it, nothing essential is missing, though the sheer volume makes it hard to extract the key facts.

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 documents the single symbol parameter, so baseline is 3, but the description adds meaning the schema does not: case-insensitivity and the tie-break rule that a shared ticker resolves to the largest market cap. That said, most of the description is about the return payload rather than the input.

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

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

The description opens with a concrete verb+resource ('One coin in full by slug ... or ticker') and implicitly scopes it as the per-coin detail view distinct from sibling list tools like gem_screener_ranked and gem_screener_picks. An agent can tell what it returns, though the framing question ('is this token a gem or a casino?') and the avalanche of field names obscure the core statement. It is clear but not cleanly differentiated from every sibling.

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 explains lookup mechanics (slug or ticker, case-insensitive, shared ticker goes to largest market cap) and alludes to the picks gate, but never states when to reach for this tool versus gem_screener_ranked or gem_screener_picks. Usage is implied rather than directed.

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, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real behavioral value: a 150-word cap, 'unknown' as the fallback for missing facts, linked sources, an appended disclaimer, a 6-hour collection cadence with pre-publish auditing, and the structural guarantees that numbers are {value, unit} and every record carries as_of.

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?

Purpose is front-loaded in the first clause, and the long middle enumeration of report sections earns its place because there is no output schema. The slash-separated run-on writing is dense and harder to parse than it needs to be, which keeps it out of the top score.

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

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

With no output schema, the description usefully characterizes the return: section list, word limit, unknown-handling, unit shape, and as_of field. Provenance and freshness are also covered. Minor gaps remain around error behavior for an unrecognized symbol and how slugs resolve against tickers.

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 parameter already documents that 'symbol' accepts a slug or ticker with examples. The description adds nothing beyond 'one coin', so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Find crypto gems: the short Degen report on one coin') and enumerates the report's sections, so an agent knows it returns a single-coin narrative rather than a ranked list. However, it never names its obvious siblings (gem_screener_coin, gem_screener_picks, gem_screener_ranked), so 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?

'A research screen, not a signal' and 'Read-only, no key' give some framing for how to treat and call it, and 'on one coin' implies single-symbol scope. But there is no explicit when-to-use vs when-not guidance and no routing to the sibling gem_screener tools for list or ranked views.

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/openWorld=false/idempotent/non-destructive, and the description adds genuinely new behavioral context: data is collected every 6 hours and audited before publishing, every number is {value, unit}, every record carries as_of, and no API key is needed. It does not contradict any annotation.

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

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

Front-loaded with the core purpose and packed with useful detail in a few sentences. Slightly dense with parentheticals (sort list, dataset provenance), but no sentence is 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?

No output schema exists, so the description must carry return-shape burden, and it partly does: it discloses that records carry {value, unit} numbers and an as_of field, plus the paging mechanism. It stops short of full field enumeration, which keeps it from a 5.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: it spells out the full sort enum including the non-obvious 'price_vs_revenue (cheapest first)', restates the 1-100/default-20 limit, and clarifies that offset pages should follow `next`.

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

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

States a specific verb+resource+scope: the full ranked list of ~215 tokenized crypto apps or chains, paged. It is clearly distinguishable from siblings like gem_screener_coin (single coin) and gem_screener_picks, and names the exact source (EventTrader's Gem Screener).

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

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

Explains what the tool returns (full ranked list vs. single-coin sibling), the sort modes available, and the paging contract via `next`. It also frames intent with 'A research screen, not a signal.' However, it never explicitly names an alternative tool or states when NOT to use this one.

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, idempotent, and non-destructive behavior. The description adds meaningful context beyond that by flagging that the record is self-attested, not third-party audited, and that only git stats are independently inspectable—an important trust caveat for how the returned data should be interpreted.

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 dense but not bloated; every clause contributes either content or an important caveat. The parenthetical caveat interrupts the flow slightly, but the overall structure effectively front-loads the core resource and then lists its contents.

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

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

For a zero-parameter, read-only tool with no output schema, the description explains the nature of the record and enumerates its main fields, which is sufficient for a first call. It could be slightly richer on what 'verification endpoints' means or how the record is obtained, but nothing critical 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?

The tool has zero parameters, so the description cannot add parameter-level meaning. The schema coverage is trivially 100%, and the description rightly focuses on what the returned record contains rather than on nonexistent inputs.

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

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

The description clearly identifies the resource as an 'AI-native provenance record' and names its concrete contents: live git stats, AI authorship percentage, founder credentials, patents, and verification endpoints. This is specific enough to distinguish it from the many other getter tools, none of which target provenance proof.

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 guidance about when to call this tool versus alternatives, nor any mention of when not to use it. The purpose implies usage, but the description never states a use case or points to a sibling tool, so an agent gets no routing help.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context by flagging 'tradeability caveats' for the models, alerting the agent that some models may have limitations. This goes beyond the annotations and does not contradict them.

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

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

The description is a single sentence that front-loads the main purpose and lists specific items. It is concise, with no filler, and every word contributes to the meaning. The caveat is integrated naturally without adding bulk.

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

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

The description covers the main content: models, themes, and strategy types, and mentions tradeability caveats. It does not elaborate on what 'themes' includes, but given the tool has no parameters and no output schema, the description is reasonably complete for an agent to decide whether to call it. A more explicit explanation of 'themes' would improve completeness.

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

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

The tool has zero parameters, so the schema provides no additional meaning. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools. The description does not need to explain parameters that do not exist.

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 'research' and a clear resource: backtest models and strategy types. It lists concrete examples (aib_sentiment, odiv, oboss; cross_exchange_arb, funding_rate, dex_replay) that distinguish it from siblings like list_backtest_surfaces, which focus on surfaces. No ambiguity remains about what the tool returns.

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

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

The description implies this tool is for retrieving backtest model and strategy-type information, but it does not explicitly state when to use it versus alternatives or provide exclusion conditions. For a simple info tool, this is acceptable, but it could have mentioned that it serves as an overview/reference for Backtest Labs capabilities.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the award amount, the report process, and the distinction between award and payment in reward_status, going 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 a single, tightly packed sentence with no filler. It front-loads the main subject and gives three concrete pieces of information that an agent can use immediately.

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

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

For a zero-parameter, read-only informational tool, the description covers the essential content: award amount, reporting process, and reward_status semantics. It does not describe the response format, but the absence of an output schema and the tool's simplicity make this a minor gap rather than a critical omission.

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

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

There are zero parameters, so the description does not need to explain parameter semantics. The 100% schema description coverage means nothing is undocumented; the description adds helpful context but is not required for parameter understanding.

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

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

The description clearly identifies the resource as the bug bounty program and specifies the key content: the flat ET10 award, how to file and track reports, and the meaning of reward_status. It does not use an explicit verb like 'get' or 'retrieve', but the informational scope is clear and distinct 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?

The description gives no explicit guidance on when to use this tool versus alternatives, and no exclusions or alternative references. It implies that the tool provides program information, but an agent is not told how to choose it over related bb_* 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?

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses important behavioral traits: simulations require an API key, cost BRRR after free runs, vary by draw number, and are scenario/risk simulations rather than forecasts. This is substantial context not available in the annotations or 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?

The description is dense but each sentence earns its place: it front-loads the core purpose, lists output details compactly, explains the draw parameter, and covers auth/cost/interpretation. There is no fluff or repetition of the title.

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

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

For a two-parameter tool with no output schema, the description is remarkably complete. It covers input semantics, output contents, authentication, cost behavior, scenario variability, and how to interpret results. An agent has everything needed to call and use the tool correctly.

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

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

Schema description coverage is 100%, and the description mostly restates what the schema already says about symbol and draw. The added instruction to 'pass draw=N for a different set of 40 scenarios' mirrors the schema property text, so the description does not meaningfully go beyond the structured input definitions.

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

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

The description uses a specific verb and resource: it provides simulated price scenarios for ONE crypto. It clearly enumerates the output elements (percentiles, horizons, share below today's price, 40 scenarios) and distinguishes this from a single-point forecast 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?

The description gives clear context for use: it requires a registered agent, explains the free tier and BRRR cost, and instructs that results should be presented as a range, never a single price target. It does not explicitly name an alternative sibling tool or state exclusions, so it stops 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope context about what the desk info covers, but does not disclose additional behavioral traits such as whether the data is static or up-to-date, or how the response is structured.

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

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

The description is a single, well-structured sentence that front-loads the topic and enumerates specific information dimensions. Every listed item adds value and there is no filler or repetition.

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

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

For a read-only, zero-parameter informational tool with rich annotations and no output schema, the description sufficiently explains what an agent will learn by calling it. It covers the key content areas and leaves no ambiguity about the tool's purpose or input requirements.

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

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

The tool has zero parameters, and schema description coverage is 100%, so there is nothing for the description to add about parameters. A baseline of 4 is appropriate because parameter semantics are trivially complete.

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

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

The description clearly identifies the resource (the Dead-Coin Buyback Desk) and explains what content the tool provides: supported chains, pricing tiers, discount model, quote TTL, and quote->reserve->settle flow. It does not explicitly contrast itself with sibling get_deadcoin_quote, but the informational scope is unmistakable.

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

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

No guidance is given on when to use this tool versus alternatives. Since get_deadcoin_quote is a sibling and likely the transactional counterpart, the description would benefit from a sentence like 'For a live quote, use get_deadcoin_quote instead.' The current text only describes content, not selection criteria.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: it is a firm bid priced from live DEX data, has a ~15 minute TTL on quote_id, and that reservation happens via separate authenticated REST. This enriches the behavioral profile beyond the annotations without contradicting them.

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

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

The description is a single dense sentence that front-loads the purpose and then lists key outputs and constraints. It is efficient, though slightly run-on, and every phrase adds value. It could be split into two sentences for readability but remains concise.

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 quote tool with no output schema, the description is complete: it lists the return fields, mentions the TTL, and notes that reservation is separate. It does not cover error conditions, but that is not essential for a simple quote operation. The context signals confirm no nested objects or output schema, so the description carries sufficient information.

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 all three parameters (chain, amount_tokens, contract_address) are already well-documented in the schema. The description does not add any parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific action: obtaining a firm USDC bid for a dead/delisted token from the Dead-Coin Buyback Desk. It lists the return fields (tier, bid_usdc, discount, quote_id) and distinguishes itself from the sibling get_deadcoin_desk_info, which provides desk info rather than quotes.

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

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

The description implies its usage: to get a quote for a dead token position. It does not explicitly state when not to use it or mention alternatives, but the purpose is self-evident and distinct from siblings like get_deadcoin_desk_info. The mention of 'reserve via authenticated REST' clarifies that this tool only quotes and does not reserve.

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 safety is covered. The description adds real behavioral context beyond that: the async lifecycle (queued/training/ready/failed) and the instruction to poll, which tells the agent this is a non-terminal-state resource that may need repeated calls.

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: identity and return contents first, usage instruction second. No filler, no restatement of the title, and the poll instruction is placed where it will be read.

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

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

With no output schema, the description usefully enumerates what comes back (status, labels, expected accuracy) and explains the polling workflow needed to use it. It could still mention behavior on an unknown or invalid classifier_id, but for a one-param read tool this is close to complete.

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

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

Schema description coverage is 100% and there is a single required parameter, so the schema already carries the semantics. The description says it fetches 'one classifier' but adds no format or ID-convention detail beyond the schema's own 'dc_...' example. 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 ('Tuatara Decide: one classifier's status') and enumerates the status domain. The word 'one' implicitly separates it from list_decide_classifiers and decide_predict, but it never names those siblings explicitly, so differentiation is by inference rather than by statement.

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?

'Poll this after creating one' gives a clear use condition tied to the create sibling flow. It does not state when not to use it (e.g. use list_decide_classifiers for all classifiers, or decide_predict once status is ready), so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description's 'Read-only' is redundant with those, but 'no auth' is genuinely additional operational context. It adds little else (no rate limits, no format), so a 3 is fair.

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 listing the content areas with no filler. It is efficient, though the compressed comma-list style is slightly dense.

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

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

For a zero-parameter, read-only info tool with no output schema, the description tells the agent enough: it is static reference content with no auth needed. The only real gap is not saying when to prefer it over the classifier-specific siblings.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics to get wrong. The description correctly implies a static, argument-free retrieval.

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 (Tuatara Decide) and enumerates exactly what it returns: product explanation, NEXUS plan allowances, limits, and benchmark evidence. This clearly distinguishes it from siblings like get_decide_classifier, list_decide_classifiers, and decide_predict, which deal with concrete classifiers/predictions rather than product docs.

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 guidance and no alternatives named. An agent must infer that this is the 'read the docs first' call before using decide_create_classifier or decide_predict; nothing states that, nor any exclusion.

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 non-obvious data-disclosure behavior beyond that — short books are aliased and open M&A baskets are withheld — plus 'no auth'. That redaction semantics is exactly the kind of context an agent cannot infer from structured fields.

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

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

Front-loaded with the core claim ('One fund in full public detail'), then a dense but well-ordered field inventory, ending with the read-only/auth note. Every clause carries information, though the mid-sentence parentheticals make it slightly heavy for a single-parameter read.

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

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

There is no output schema, so the description must carry the return contract — and it does, enumerating the fields returned and flagging the two cases where constituents are withheld or aliased. With annotations covering the safety profile, nothing material is missing for a correct invocation.

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

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

Schema coverage is 100% for the single symbol parameter, so the baseline is 3. The description adds value above that by naming the source of valid values (list_funds) and giving concrete examples of symbol formats (AIB symbols, MA-RIPPLE, FTA-CRYPTOS, FTA-STOCKS, EVENT-CARD), which helps the agent construct a valid call.

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 ('Get') and resource ('one fund') and immediately enumerates the scope of the payload: theme, mandate, direction, status, constituents, price, return, URLs, focus areas. This clearly separates it from siblings like list_funds (enumeration) and get_fund_history (time series).

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

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

Gives the required precondition for the input ('Symbol from list_funds') and even lists valid symbol families, which tells the agent where to source the argument. It does not explicitly say when to prefer this over get_fund_history or get_fund_methodology, so it stops short of full alternative routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real context beyond them: sign-correction of short-book returns, disclosure rules, what is withheld and why, and a not-advice notice — useful behavioral detail about the content returned.

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

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

It is a single dense sentence followed by one usage sentence — front-loaded and mostly waste-free. The enumeration is long but each item earns its place by telling the agent what the reference contains.

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 explaining returns, and it does so by listing the categories of methodology content available. An agent knows what it will get without needing a schema, though exact structure/format remains 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?

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the schema needs elaboration and the description correctly does not invent parameter semantics.

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

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

The description states a clear subject: the measurement methodology behind every fund figure, enumerating coverage areas (index construction, since-inception returns, status meanings, disclosure rules, URLs). This cleanly distinguishes it in spirit from get_fund/get_fund_history, though it never names those siblings as the data-vs-methodology 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 gives an explicit trigger: 'Use it when a user asks how a fund figure is measured or what a status means.' That is clear context for invocation, but it does not state when NOT to use it or point at an alternative tool for raw fund data.

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=false. The description adds relevant auth/plan context ('no plan needed', 'plans that include it (paid NEXUS plans)') and enumerates what the info covers, though it does not describe return format or rate limits.

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

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

One compact sentence enumerates the API info scope followed by a short eligibility clause. It is front-loaded and 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?

For a zero-parameter, read-only info tool with no output schema, the description sufficiently identifies what the caller will learn and the plan requirement. It does not describe the return format, but that is a minor omission given the tool's documentation nature.

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

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

The tool has zero input parameters, so there is no parameter semantics to document. Baseline 4 applies.

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

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

States the specific resource (EventTrader Headlines API) and enumerates the exact content covered: field meanings, 24-hour score coverage, plans, filters and limits. It does not explicitly contrast with siblings such as get_headlines_sample or search_headlines_api, so sibling differentiation is missing.

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

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

The description implies this is the documentation/info endpoint, and says it is read-only with no plan needed, but it never states when to use it instead of get_headlines_sample, search_headlines_api, or headline_event_card. Usage guidance is therefore implicit.

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 closed-world behavior. The description goes beyond them by disclosing the sample's hard limits: exactly 5 items, a 60-minute freshness lag, and the no-plan auth requirement — real behavioral facts an agent could not infer from 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 tight sentence front-loads the source and scope, then the constraint and access requirement. No filler, nothing repeated from the title 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?

For a zero-param, no-output-schema read tool with rich annotations, the description covers what is returned, how fresh it is, how many items, and the access requirement — everything needed to decide and call it. Only the routing to the full-query sibling is absent.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids inventing parameter semantics.

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

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

The description names the specific API (EventTrader Headlines API), states the exact scope (5 newest headlines at least 60 minutes old), and the return shape (full item shape). It clearly reads as a preview/sample variant, though it never names the full-query sibling (search_headlines_api / get_headlines_api_info) it is distinguished from.

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

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

It conveys that this is a free sample requiring no plan, which implies when to reach for it over the paid headline tools. But there is no explicit statement of when not to use it or which sibling to use for full/paid headline access, so usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds only the generic qualifier 'detailed information' and does not describe return shape, pagination, or errors, but it does not contradict 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 that states the verb and object with no wasted words. It is concise and appropriately sized for a simple lookup 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?

For a one-parameter read-only lookup, the description is minimally sufficient to invoke the tool with a market_id. However, since there is no output schema, 'detailed information' is left vague, and the description does not clarify the distinction from list_markets or search_markets.

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 market_id and its required status are documented in the schema. The description adds no extra meaning about format, allowable values, or lookup semantics, so it stays at the 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?

The description states a clear action ('Get') and resource ('a specific market'), which is enough to distinguish it from broad list/search siblings. It is not a tautology, though it does not explicitly name alternatives or specify what 'detailed information' includes.

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 'specific market' implies this tool is for retrieving details for a known market_id rather than listing or searching markets. However, it does not explicitly state when to choose this over list_markets or search_markets, nor does it provide exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond what annotations provide, such as default depth behavior or market scope. It does not contradict annotations, but it also doesn't add value beyond them.

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

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

The description is a single short sentence with no wasted words. It is front-loaded with the core action and resource. It could arguably be more informative, but for a simple tool it is appropriately concise.

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

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

For a simple read-only tool with full schema coverage and safety annotations, the description is mostly complete. However, it doesn't mention the default depth of 10 or clarify what 'market' refers to (e.g., which market type), and there is no output schema to clarify the return format. An agent could call it correctly, but some context is left implicit.

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

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

Schema description coverage is 100%, so both parameters (depth and market_id) are already documented in the schema. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description 'Get orderbook for a market' clearly states the verb (get) and resource (orderbook for a market). It is concise and unambiguous. However, it does not explicitly differentiate from the sibling tool get_arena_orderbook, which likely serves a similar purpose in a different context, so it loses a point for lack of 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?

The description implies usage: call this when you need the orderbook for a market. It does not state when not to use it or mention alternatives like get_arena_orderbook. The context is clear enough for a simple read operation, but there is no explicit guidance on choosing between this and similar orderbook 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 declare readOnly, idempotent, non-destructive, and openWorld false, so the description adds little beyond 'current' and 'statistics,' implying a point-in-time snapshot without side effects. This is useful but minimal; no additional context like rate limits, response shape, or platform scope is provided.

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

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

The description is a single short sentence with no filler, and the key word 'current' is front-loaded. It is efficient, though slightly under-specific about what 'statistics' refers to.

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 zero parameters and strong safety annotations, the invocation requirements are complete. However, there is no output schema and the description does not clarify what 'status and statistics' specifically covers, leaving the return payload somewhat ambiguous for an agent.

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

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

The input schema has zero parameters, so there is nothing for the description to document about arguments. The baseline for a 0-parameter tool is 4, and the description does not need to compensate for missing parameter explanations.

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

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

The description clearly identifies a read operation against the platform as a whole with 'Get current platform status and statistics,' and the verb 'Get' is explicit. It does not explicitly distinguish from related state/status siblings like get_arena_state or get_btc_pool_state, though 'platform' implies broader scope.

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

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

There is no guidance about when to use this tool versus the many other status/state tools in the sibling list, nor any conditions, exclusions, or alternatives. For a zero-argument global endpoint this is less critical, but the description still leaves the choice 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=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral detail beyond annotations: thin rounds return low_sample=true instead of fabricated precision, and the consensus price is defined as stake-weighted median. This gives the agent more insight into edge cases and output semantics.

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

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

The description is a single dense sentence that front-loads the core purpose and then enumerates metrics efficiently. While it packs in many details, each element earns its place; it borders on run-on but remains scannable and useful.

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 present, the description carries the burden of explaining return values. It enumerates the key metrics (consensus price, dispersion, quartiles, bullish/bearish split, low_sample flag) and clarifies edge-case behavior, giving an agent enough context to interpret results 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 description coverage is 100%, with each parameter (pool, round, history_window) already documented with defaults and ranges. The description references the historical percentile baseline, which relates to history_window, but does not add param-specific detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Aggregated crowd analytics for one prediction-pool round', then details the exact metrics returned. This makes the tool's purpose unmistakable and clearly distinguishes it from sibling pool tools like get_btc_pool_state or get_btc_pool_history.

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

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

The description clearly scopes usage to a single prediction-pool round and notes it is read-only, which helps an agent choose it for analytics. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds only the word 'current,' which provides minimal behavioral context beyond the name. It does not mention what kind of prices are returned, data freshness, or response behavior.

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

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

The description is a single concise sentence with no filler. It is front-loaded and every word earns its place, though it is somewhat terse.

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

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

The tool is simple, has one fully documented parameter, and safe annotations. However, there is no output schema and the description does not clarify what the returned 'prices' include, leaving an agent with some ambiguity about the response.

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%: market_id is described as 'Market identifier.' The description's 'for a market' restates that meaning without adding any format, examples, or constraints 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 clearly states the action ('Get current prices') and the resource ('a market'). It is easy to understand what the tool does, but it does not differentiate itself from siblings like get_market or get_orderbook.

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

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

There is no guidance about when to use this tool versus alternatives. It does not mention exclusions, preferred use cases, or distinguish itself from get_market, get_orderbook, or get_deadcoin_quote.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds meaningful behavioral detail beyond that: metrics come only from real rows, a strategy with no runs returns a note rather than fabricated numbers, and the two measurement windows are explicitly different. No contradiction with 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 dense and mostly efficient, with every sentence contributing. The backtick-heavy second sentence is slightly run-on and could be broken up, but it contains necessary distinctions rather than filler.

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

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

For a single-parameter, read-only tool with no output schema, this description covers inputs, return semantics, the difference between two measurement windows, and the no-data failure behavior. An agent has enough information to invoke the tool correctly and interpret its response.

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?

Although schema coverage is 100%, the description adds significant semantic value beyond the schema: it explains the difference between concept ids and leaderboard slugs, gives concrete examples of each, and clarifies which window each metric covers. This meaningfully improves an agent's ability to supply the correct parameter.

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

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

Clearly states the tool returns grounded backtest metrics (ROI/Sharpe/win-rate/drawdown) for a strategy concept, with explicit differentiation between latest_metrics.period and leaderboard headline_period. This distinguishes it from other backtest-related sibling tools and makes its purpose unmistakable.

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?

Provides clear context on when to use it and exactly what inputs are accepted (concept id or leaderboard slug) with examples. It doesn't explicitly name sibling alternatives or exclusion conditions, but the usage scope is well-defined and not misleading.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context by stating the spec is 'Generated from the live scoring config', indicating the data is dynamic and reflects current configuration. It also lists the exact fields the agent can expect, which goes beyond the annotations.

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

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

The description is two sentences with zero filler. The first sentence front-loads the main content list, and the second adds a single relevant note about the data source. Every phrase earns its place, making it both concise and structured.

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, zero-parameter tool with no output schema, the description fully covers what an agent needs: it lists the complete set of information returned (thresholds, limits, unlocks, points, bonus, mechanics) and notes the source freshness. No critical details are missing for correct invocation.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The description correctly avoids discussing parameters. Per the rubric, a 0-parameter tool earns a baseline of 4, and no additional parameter explanation is needed.

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 ('get') and resource ('trust-ladder spec'), and enumerates the exact content (score thresholds, rate limits, unlocks, points per action, AI-nativeness bonus, upgrade mechanics). This clearly distinguishes it from the sibling 'get_trust_signal', which likely returns a per-user signal rather than the ladder configuration.

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

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

The description gives clear context: it returns the complete ladder spec, so an agent understands when to call it (when it needs the ladder's scoring rules). It does not explicitly name alternatives or exclusions, but the specificity of the content makes the usage intent obvious. A minor omission is the lack of a direct 'use this instead of X' note.

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, so the bar is lower; the description adds meaningful output behavior: it returns indexed metadata, a page link, recent trades, top holders, and a top-10-concentration rug-flag. No contradiction with annotations.

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

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

Two dense sentences front-load the purpose and delimit scope, then enumerate output categories and usage context. No filler or repetition of schema details.

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 single-token retrieval with rich annotations and complete schema descriptions, the description covers what the tool returns, how to source the address, and its place in the workflow. The absence of an output schema is compensated by enumerating the output groups.

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 applies: parameters (token_address, chain_id, trades_limit, holders_limit) are already documented with defaults and chain tie-break details. The description only loosely maps 'recent trades and top holders' to the limit params and adds little parameter-specific meaning.

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

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

The description names a concrete operation ('get token by address') and clearly delimits scope to ONE launchpad token, enumerating the returned metadata categories. This distinguishes it from sibling tools like launchpad_list_tokens, which covers the full set.

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

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

It gives explicit invocation context: use after launchpad_list_tokens or with a launch-receipt address. It does not spell out 'when not to use' compared with all other launchpad siblings, but the singular-vs-list contrast and sequencing make the intended workflow clear.

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 idempotentHint=true, so safety is covered. The description adds behavioral detail by disclosing that it returns two categories of platforms (integrated vs site) and exactly what fields are returned, giving the agent a clear picture of the output beyond the structured metadata.

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

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

The description is dense but efficiently packed with relevant detail. The primary action and resource are front-loaded, followed by the output fields and usage hint. Every sentence earns its place; there is no fluff or repetition.

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

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

Given there is no output schema, the description compensates by enumerating the returned fields (slug, availability, fee, integrated/site status). It also covers the chain_id options and how to consume the result. Minor gaps like the exact data type of 'live availability' are acceptable for a read-only list tool.

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

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

The schema already fully documents chain_id (100% coverage), so baseline is 3. The description adds context by restating the allowed values and clarifying that the chain_id selects which Arc network to list launchers for, reinforcing the parameter's role in the tool's purpose. This is helpful but not essential.

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

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

The description clearly states the verb 'List' and the resource 'launcher platforms on Circle's Arc', and specifies the exact information returned (slug, live availability, fee, integrated vs site). It distinguishes itself from sibling tools like launchpad_launch_token by focusing on enumeration, making its purpose unmistakable.

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 tells the agent what to do with the output ('Pass the slugs as `platforms` to launchpad_launch_token'), implicitly defining when to use this tool (before a cross-launch). It also names the valid chain_id values. It does not explicitly contrast with alternatives like launchpad_list_tokens, but the purpose is clear enough to route correctly.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context (non-custodial launchpad, returned data fields, 'free discovery feed'), but it does not disclose other behavioral details such as rate limits, pagination, auth requirements, or error behavior.

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

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

The description is two short sentences with no filler. It front-loads the core action and resource, packs the relevant output data into a compact list, and the 'free discovery feed' phrase reinforces usage context without bloating the text.

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

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

For a read-only list tool with zero required parameters and fully documented optional parameters, the description plus schema and annotations are adequate for correct invocation. The description provides the key output themes, though it does not detail response structure or pagination; this is a minor gap for a list endpoint.

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 all four parameters already have meaningful descriptions (sort, limit, status, chain_id). The tool description adds no extra parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'List tokens on the non-custodial EventTrader launchpad (Robinhood Chain)' and enumerates the content ('live curve prices, graduation progress, volume'). This cleanly distinguishes it from siblings like launchpad_get_token (single token), launchpad_list_launchers (launchers), and launchpad_launch_token (mutation).

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

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

The description implies a discovery use case with 'Free discovery feed', and names the resource being listed, but it does not explicitly say when to use this tool versus alternatives, nor does it provide exclusions or point to a sibling like launchpad_get_token for single-token lookups.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds valuable behavioral context: it reads the curve on-chain (confirming read-only behavior) and discloses that sell transactions include the required ERC-20 approve. This goes beyond the annotations without contradicting them.

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

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

The description is two sentences, front-loaded with the core purpose and key output detail (unsigned transactions), followed by a concise behavioral note. Every sentence earns its place with no filler.

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

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

While there is no output schema, the description covers the essential return elements: the quote and the unsigned transaction(s), with a special note for sells. It does not detail the structure of the quote or the transaction format, but for this tool's complexity (5 params, no nested objects), the description gives the agent enough to invoke it correctly and interpret the high-level result.

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. The description adds general trade mechanics (e.g., sells include approve) but does not elaborate on parameter-specific semantics beyond what the schema already provides. It does not compensate further for any gaps, so a 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 a specific verb–resource relationship: it provides a live bonding-curve quote and unsigned buy/sell transaction(s) for a launchpad token. It also distinguishes itself from sibling quote tools like get_deadcoin_quote by scoping to launchpad tokens and by explicitly mentioning the unsigned-transaction output.

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

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

The description clearly implies when to use the tool: when the agent needs a quote or unsigned transaction for a launchpad token to sign with the user's own wallet. It does not explicitly name alternatives or state when not to use it, but the 'launchpad token' qualifier provides sufficient context to differentiate from unrelated 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful context that the returned identifiers are disjoint from prediction-market ids, but doesn't disclose pagination behavior or whether the list is sorted. With annotations covering the core behavioral traits, a 3 is appropriate.

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

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

A single sentence that front-loads the core purpose, then adds the key disambiguation from list_markets. Every word earns its place; no filler.

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

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

For a simple read-only list tool with full schema coverage and annotations covering safety, the description is nearly complete. The only minor gap is that it doesn't mention pagination behavior or result ordering, but the offset/limit parameters in the schema make this fairly self-evident.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description doesn't add parameter-level detail beyond what the schema provides, so the baseline 3 is correct.

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

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

The description uses a specific verb ('Enumerate') and resource ('CLOB trading pairs'), and explicitly distinguishes the identifier space from list_markets. This makes the tool's purpose immediately clear and differentiates it from a sibling 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?

The description explicitly states that CLOB pairs are the valid inputs to get_prices/get_orderbook, and contrasts with list_markets which returns prediction-market ids. This gives clear guidance on when to use this tool versus alternatives.

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=false, so the safety profile is clear. The description adds that the tool returns user-specific data ('your classifiers... your plan... weekly decisions'), which is useful scope context beyond annotations. However, it does not disclose authentication requirements, rate limits, or return format details.

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

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

The description is a single sentence fragment that is not front-loaded with a clear action. While short, it is under-specified and leaves the core purpose ambiguous, rather than being concise and informative.

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 should clearly explain what the tool returns. It hints at classifiers, plan, limit, and weekly decisions, but the phrasing is vague and does not provide a usable return-value overview for an agent.

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 clarify. Schema description coverage is 100% and no parameters exist, meeting the baseline score of 4.

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 is a fragment that names resources ('your classifiers', 'your plan', 'classifier limit', 'weekly decisions') without a clear verb like 'list' or 'retrieve'. It does not distinguish the tool from siblings such as get_decide_classifier or decide_create_classifier.

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

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

No guidance on when to use this tool versus alternatives is provided. There is no indication of prerequisites, context, or exclusions.

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 and no auth, but the description adds behavioral context beyond them: 'no auth', 'Percentages and index prices only; capital figures are never published', which constrains what data can be expected. It does not disclose ordering rules or any rate limits, keeping it from a 5.

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

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

A single dense sentence, front-loaded with the resource and scope. Every clause (ranked list, fields, data limits, downstream symbols) earns its place, though the em-dash-heavy packing makes it slightly heavy to parse.

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 burden and does so by enumerating the returned fields and noting the symbols feed sibling tools. It omits ordering/pagination behavior, which would be needed for fully correct invocation.

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

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

Schema description coverage is 100% with only 2 parameters, so the schema already documents both limit and status. The description restates the status values (live / paper / standing) but adds no syntax or semantics beyond what the schema provides; 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 (list) and resource (Tuatara-managed funds) with enumerated return fields (name, sleeve, long/short, status, index price, % return). It explicitly names the siblings get_fund and get_fund_history whose take it feeds, so an agent can place it in the workflow without opening another schema.

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

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

The closing sentence routes the agent: this tool returns the symbols that get_fund and get_fund_history consume, strongly implying 'list first, then drill in'. However, it never states exclusions (e.g., when to prefer get_fund directly) or pagination/limit guidance, so it falls just short of explicit when-not guidance.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal extra behavioral context beyond 'available' and 'filtering', and does not mention return shape or pagination details, but those are not contradicted by structured 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?

The description is one short sentence that conveys the core operation, resource, and an important scoping trait ('available'). There is no filler or repetition of schema details, and the most important information is front-loaded.

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

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

For a simple, read-only listing tool with fully documented parameters and no output schema, the description is reasonably complete: it says what the resource is, that it lists available markets, and that filtering is possible. It could be more complete by noting relationship to search_markets or return ordering, but nothing essential is missing for invoking 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?

The input schema documents all four parameters with descriptions, and the schema coverage is 100%, so the baseline of 3 applies. The tool description only says 'optional filtering' and does not add parameter-specific semantics 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 clearly identifies the verb ('List'), the resource ('prediction markets'), and the scoping concept ('available' plus filtering), so an agent can understand what the tool does. It is easy to distinguish from get_market, which targets a single market, but there is no explicit comparison to the sibling search_markets tool, so it stops short of a 5.

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