Market Intelligence API (core)

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is the $0.05 cost, the live-vs-stale distinction against decision.sample, and the explicit scope exclusion (no trade plan, execution check, evidence or risks). It does not mention rate limits or what happens when a symbol is unknown, which keeps it short of a 5.

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

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

Two sentences, front-loaded with the price and the returned payload, then the sibling routing. Despite being dense, every clause carries selection-relevant information and none 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?

There is no output schema, so the description carries the return-value burden, and it discharges it by listing the fields produced and the ones deliberately omitted. Combined with the cost and freshness cues, an agent has everything needed to choose and call it correctly.

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

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

Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds meaning by tying the optional 'side' parameter to its outcome ('a GO/WAIT answer for a side'), clarifying why an agent would supply it rather than omitting 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?

States a concrete verb+resource (a live trading decision) and enumerates the returned signals: action (STRONG_BUY..STRONG_SELL), direction, conviction, GO/WAIT, pillar stances, measured hit rate. It also names the full-server counterpart get_decision, so the agent can distinguish it from siblings without opening a schema.

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

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

Explicitly instructs 'Use as the default decision' and then routes away from the two nearest siblings: decision.pre_trade is only go/no-go timing for a side, and decision.sample is free but an hour old. When-to-use, when-not, and alternatives are all present.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing the return shape and the six check categories (order flow, momentum, volatility, adverse events, regime, news/filings of the last 24h). It stops short of noting latency or data-freshness caveats, so not a 5.

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

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

Front-loads the decision scenario in a quoted user-voice framing, then lists outputs and routing in two compact sentences. Slightly dense with enumeration, but every clause earns its place and there is no filler.

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

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

Despite having no output schema, the description fully specifies the return contents (verdict, score, underlying checks) and the routing condition, so an agent has everything needed to call it correctly against a 3-parameter, read-only analytic tool.

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

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

Schema description coverage is 100% and both enums are self-documenting, so the schema carries the parameter burden. The description only loosely implies that symbol and side are the inputs already known to the caller, adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

The description names a concrete verb and resource: it evaluates whether 'now' is a good moment to buy/sell a given SYMBOL, and enumerates the verdict output (FAVORABLE, CAUTION, UNFAVORABLE). It explicitly distinguishes itself from the sibling decision.lite by stating this is for go/no-go timing only.

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?

Explicit when-to-use ('when you already know the symbol and side and only need go/no-go timing') and an explicit alternative for the other case ('for an action with conviction use decision.lite'). Nothing is left to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower; the description usefully adds the staleness constraint (delayed at least an hour) and the included outcome horizons. However, it conflicts with its own schema, claiming roughly 40 symbols while the schema says 'all ten symbols,' which undercuts trust in the returned universe.

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?

Information is dense but front-loaded in one sentence, with the delayed-access caveat placed before the call-to-action. The marketing framing ('FREE', 'premium', 'Judge the decisions before buying') adds tone but little wasted length.

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

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

With no output schema, the description carries the burden of describing returns and does so concretely (action, direction, conviction, pillar scores, plus 1h/4h/24h follow-through). The only completeness gap is the unresolved symbol-count discrepancy between description and schema.

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

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

Schema coverage is 100% for the single optional symbol parameter, so baseline would be 3; but the description's example symbol list and 'about 40' universe directly contradict the schema's 'omit for all ten symbols.' For a caller deciding whether to pass a symbol, this is misleading rather than additive.

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

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

The description states a specific resource and scope: the latest hourly decision per symbol (action, direction, conviction, pillar scores) plus realized 1h/4h/24h price outcomes, positioned as a free sample of the premium product. It is clearly distinguishable from market or token tools, though the boundary with the sibling decision.lite is only implied, not stated.

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

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

It gives an explicit usage framing: 'Judge the decisions before buying a live one,' i.e. use this as a free preview before purchasing live signals. There is no explicit when-not-to-use or named alternative (e.g. decision.lite vs decision.pre_trade), so it falls 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 readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds genuinely new context: submissions are human-reviewed and influence 'the next routes,' and it is free. It does not say anything about latency, retention, or whether feedback is swallowed silently, but that is beyond the annotations' scope.

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

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

Two sentences, zero filler, with the incentive ('FREE') and the action front-loaded and the audience/feedback loop trailing. Every clause earns its place.

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

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

For a zero-required-parameter, read-only feedback sink with no output schema, the definition covers purpose, audience, and what content belongs in it. The only gap is what an agent should expect after submitting (any acknowledgment or response), which is minor.

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

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

Schema description coverage is 100%, so the four parameters are already documented in the schema and the baseline is 3. The examples in the description loosely map to 'missing', 'route', and 'message', but they do not add syntax, format, or precedence information beyond what the schema already provides.

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

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

The description states a specific verb and resource — tell the operator what was missing or wrong — and gives concrete examples (expected route/tool, symbol without data, confusing parameter). It is unmistakable from the market/decision siblings, which all serve data retrieval rather than feedback capture.

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 clearly frames the three situations that justify a submission (missing route/tool, missing data, confusing parameter) and notes the audience ('read by a human'). It stops short of saying when not to use it or what happens after review, so it is context-rich but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the schema: the $0.002 cost per call, UTC timezone, and that data comes from official calendars (BLS, BEA, ECB). Return format/pagination is not described, keeping it out of 5 territory.

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, front-loaded with what the tool returns and back-loaded with the call-to-action. No filler, though the parenthetical cost and long event list make it 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 read-only, zero-required-parameter calendar lookup with no output schema, the description covers source, timezone, cost, event scope, and the intended moment of use. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% with enums for region and importance, so the schema already documents all three parameters thoroughly. The description adds only light reinforcement ('in UTC with importance') and no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names a specific resource (upcoming market-moving events) and enumerates the concrete event types covered (CPI, jobs report, PCE, GDP, PPI, JOLTS, FOMC, ECB), plus the authoritative sources (BLS, BEA). It is clear what the tool returns, though it does not explicitly contrast itself with siblings like market.explain_move or news.symbol.

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?

'Check before opening a position' gives a clear, actionable usage context tied to pre-trade workflows. It stops short of naming alternatives or stating when NOT to use it, so it falls one notch below the explicit when/alternative guidance 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 readOnly/idempotent/non-destructive/openWorld, so safety is covered; the description then adds real value the annotations do not: a cost signal ($0.02), the 15-minute measurement window, the full set of data sources consulted, and the return shape (drivers with direction and weight plus a one-sentence summary). It stops short of stating auth requirements or rate limits, but goes well beyond the structured hints.

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 question, then cost, then scope and output. Two sentences with no filler; the parenthetical source list is dense but earns its place by telling the agent exactly what evidence the answer synthesizes.

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 burden of describing the return and does so (drivers with direction/weight plus a one-sentence summary), and it scopes time window and asset classes. An agent has enough to call it correctly; only cross-tool routing and any auth/cost caveats beyond price are 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?

Only one parameter (symbol) with 100% schema description coverage and inline examples (ETHUSD, NVDA, TSLA), so the schema already carries the semantics. The description adds the universe of supported symbol types, but no format or normalization detail beyond the schema; 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?

Specific verb+resource: it explains the 15-minute price move for a symbol via enumerated drivers (on-chain flow, unusual activity, smart money, perp crowding, news, filings, insiders). The causal framing clearly distinguishes it from snapshot/summary siblings, though it never names those 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?

Usage is implied by the opening question ('Why is a symbol moving?') and the stated asset-class coverage (crypto, tokenized stocks, US stocks), which helps scoping. However there is no explicit when-to-use vs when-not, and no mention of sibling tools like market.snapshot or market.summary that an agent would need to disambiguate.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description is free to focus on behavior. It does that well, describing the return shape: ranked symbols with supporting AND conflicting evidence grouped by source, typed risk factors, data quality, live 1h hit rate, and next calls. It omits auth requirements and rate limits, but for a read-only scan the return-content disclosure is the higher-value information and is present.

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 front-loaded with the tool's purpose and then layers on the return shape, the positioning against screeners, and the objective list. It is dense but every clause contributes; the trailing objective enumeration is borderline redundant with the schema enum.

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

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

There is no output schema, so the description carries the burden of describing returns – and it does so thoroughly. For an 11-parameter tool with full schema coverage, the missing piece is only explicit parameter semantics and when-not guidance. An agent has enough to select and invoke it correctly.

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

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

Schema coverage is 100%, so all 11 parameters are already documented in the schema, which sets the baseline at 3. The description's mention of the objective values merely repeats the schema enum and adds no new semantics about window, include, filters, or thresholds. No parameter meaning is added beyond what structured fields already provide.

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: a goal-driven scan that returns ranked symbols with evidence, risk factors, data quality, and track record. The scope is precise and easy to tell apart from a generic screener. It does not, however, explicitly contrast itself with named siblings like market.snapshot, market.summary, or decision.lite, so an agent must infer the boundary.

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

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

Gives a clear usage rule – 'Use instead of chaining screeners' – which tells the agent when this tool is the right choice versus manually composing screeners. It also enumerates the valid objectives. It stops short of explicit when-not conditions or naming the specific sibling tools it supersedes.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds real value beyond them by disclosing the price point ($0.001), the point-in-time nature ("right now"), and the exact response contents; it stops short of rate limits or data freshness caveats.

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 opens with the cost differentiator and then lists the payload. No filler; every clause adds information.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the fields. For a 2-parameter read-only tool that is nearly complete; only the relationship to sibling summary/explain tools 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% and the enum/default for window is fully documented in the schema, so baseline 3 applies. The description only implies the symbol scope ("one symbol") and says nothing about the window parameter that the schema does not already cover.

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

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

Names a concrete resource (headline numbers for one symbol) and enumerates the returned fields (price, change, buy pressure, signal, event, confidence, trade count), so the agent knows exactly what it gets. It does not, however, distinguish itself from near-siblings such as market.summary or market.explain_move.

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?

"Cheapest call ($0.001)" gives an implicit routing hint — use this when cost matters and a full summary is not needed — but it never states when to prefer market.summary or other siblings over this one, nor any preconditions. Usage is implied rather than explained.

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, openWorldHint=true and destructiveHint=false, so safety and idempotency are covered. The description adds that results come in 'one call' and include 'data freshness', but does not cover rate limits, auth, or return shape. With annotations carrying the behavioral burden, 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?

Two tight sentences: the first front-loads what is returned, the second handles routing. No filler or repetition of 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?

For a read-only, zero-required-param tool with no output schema, the description conveys the returned dimensions and the alternative route. Missing only minor detail such as response shape expectations, which is acceptable given the rich annotation coverage.

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 'window' parameter already documents its enum values and default, so the schema does the heavy lifting. The description adds no window semantics beyond that, which is the expected baseline when coverage is 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?

States a concrete verb and enumerates the specific content returned (breadth, buying pressure, momentum, unusual activity, data freshness), so the agent knows exactly what this resource provides. It also explicitly distinguishes itself from the sibling market.opportunities.

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

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

Gives an explicit use case ('breadth, regime and the top movers in one call') and names the alternative tool plus the condition that selects it ('for a goal-driven scan use market.opportunities'). The routing decision is unambiguous.

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, open-world, non-destructive, so the safety profile is covered. The description adds real context beyond that: per-call cost ($0.003), newest-first ordering, and the returned fields (publisher attribution, sentiment, event type, materiality where classified).

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 with the core purpose and cost front-loaded before the field inventory. Efficient, though the trailing clause listing return fields is slightly list-like and the parenthetical price interrupts the flow.

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

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

For a simple two-parameter read-only tool with no output schema, the description covers what is returned, ordering, and cost. Minor gaps remain (no note on empty results or result caps beyond 'limit'), but 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%, so both parameters are already documented, including the symbol examples the description repeats. The description adds no meaning for 'limit' or pagination behavior, so baseline 3 applies.

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

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

States a specific resource ('News for one symbol') with scope qualifiers (headlines plus SEC filing events tagged with the ticker) and gives concrete symbol examples. An agent immediately knows this retrieves per-ticker news, distinct from the market/decision/token 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?

Usage is implied by 'for one symbol' and the price tag ($0.003) hints at a metered call worth weighing, but there is no explicit when-to-use, when-not-to-use, or alternative named. The single-symbol scoping is the only routing signal.

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, idempotent, and non-destructive. The description adds valuable context: it is free, covers specific timeframes and horizons, and includes the perp crowding record. No behavioral risks are disclosed, but none are relevant for a read-only stats 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 description is front-loaded with the key value ('FREE: live hit rate...'), packs detailed breakdowns efficiently, and ends with a clear call to action. 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?

With no output schema, the description sufficiently explains what the tool returns (hit rate over timeframes, by signal and confidence, plus crowding record) and when to use it. Nothing critical is missing for a read-only, parameterless statistics tool.

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

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

The tool takes no parameters, so the schema provides no semantics. The description correctly does not need to explain any inputs. Baseline 4 is appropriate for zero-parameter tools.

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 (live hit rate of published signals) and its scope (7/30/90 days, per horizon, by signal and confidence, plus perp crowding record). It does not explicitly differentiate from siblings, but the purpose is specific and unambiguous.

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

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

The description provides a clear usage context: 'Judge the signals before buying them.' This tells the agent when to use the tool, though it does not mention 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds two pieces of context annotations cannot carry: the per-call cost ($0.03) and the provenance of the signal (SEC filings). It does not discuss latency, rate limits, or partial-failure behavior when some tickers are invalid.

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

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

One dense sentence with zero filler; the batching limit and cost land early, followed by the returned fields. Nothing can be removed without losing information.

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

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

With no output schema, the description correctly compensates by enumerating the returned metrics, and the read-only annotations remove the need to explain side effects. It is nearly complete, missing only error/partial-result behavior for large or invalid ticker lists.

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 enforces minItems 1 / maxItems 10. The description still adds semantics beyond the schema by reinforcing the 10-per-call ceiling and the 'US-listed' constraint, which the ticker parameter description does not state. It does not clarify behavior for delisted, non-US, or invalid tickers.

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 (fundamentals of US-listed companies) and enumerates the payload: revenue, earnings, margins, growth, balance sheet, and a SEC-filing signal. Clear enough to invoke without opening the schema, though it never distinguishes itself from market-level siblings like market.snapshot or market.summary.

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 'up to 10 US-listed companies in one call' implicitly recommends batching multiple tickers, but there is no explicit when-to-use guidance, no when-not-to-use, and no named alternative among the 15 sibling tools. Usage must be inferred from the batching hint.

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/idempotent, so the safety profile is covered. The description adds real behavioral context: what gets risk-checked, the three verdict tiers, liquidity thresholds implicitly, and that results include sell simulation and v4 hook powers.

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 resource and scope followed by the risk-checking detail. Every clause earns its place, though the nested enumeration makes it harder to scan.

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 reasonably well, naming the fields an agent will get (liquidity, sell simulation, hook powers, first trades, verdict). It could say more about ordering or result shape, but the essential content is present.

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

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

Schema coverage is 100%, so all six parameters are documented in the schema, and the description adds little beyond restating the 60-minute look-back and the two chains. The description's 'Base or Ethereum' actually narrows what the chain enum description lists (arbitrum, optimism, polygon), a mild inconsistency rather than added clarity.

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 (new token launches), scope (last hour, Base/Ethereum), and the exact enrichment performed (Uniswap v2/v3/v4/Aerodrome pools vs ETH/WETH/USDC with liquidity checks, sell simulation, verdict). An agent can distinguish this from token.risk, which checks a single known token.

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

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

The description implies the use case (discovering freshly-launched tokens with risk verdicts) but never states when to prefer this over siblings like token.risk, market.opportunities, or decision.lite, nor any exclusions. Usage is left to inference.

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

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

With readOnlyHint/idempotentHint already declared, the description still adds substantial value: the full set of EVM checks (honeypot sim, mint/blacklist/pause/fee functions, LP burn, buy tax, flow), the Solana-specific checks, and the returned verdict enum (LOW_RISK/CAUTION/HIGH_RISK). It answers what gets analyzed and what comes back, which annotations alone do not.

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 use case ('Due diligence before buying any token') and dense with distinct, non-redundant facts. The EVM/Solana check lists are long but each item carries screening meaning, so it stays informative without much waste.

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

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

For a multi-chain analysis tool with no output schema, the description covers chains, address formats, the checks run per ecosystem, the verdict taxonomy, and the sibling alternative. Nothing essential to correctly invoking or interpreting it 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 both parameters are already documented, including the chain enum and the address format. The description restates the chain list without adding syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb/resource (token risk due diligence) with concrete scope and enumerates the exact checks performed for EVM and Solana mints. It explicitly distinguishes itself from the sibling token.swap_quote, so an agent can route correctly without opening either schema.

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

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

The closing sentence gives both a when-to-use ('Use before buying a token') and a named alternative for the adjacent need ('for the price you would get on chain use token.swap_quote'). This is explicit routing guidance rather than implied 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint. Beyond those, the description adds genuinely new behavioral context: a fixed cost ($0.002) and explicit simulation semantics ("Simulated, nothing executed"). It stops short of disclosing quote validity/expiry 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 dense, front-loaded sentence that leads with the trigger ("Right before an on-chain swap") then the deliverables. Slightly packed, with the cost parenthetical interrupting the main clause, but every element carries information and there is no filler.

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

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

With no output schema, the description takes on the burden of describing returns — and does: price impact, minimum received at your slippage, and alternatives — plus the supported chains and best-route behavior. An agent has everything it needs to call this quote 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%, so the baseline is 3. The description goes slightly beyond the schema by tying slippage to a concrete outcome ("minimum received at your slippage") and spelling out the routing/chain context that frames sell/buy/chain, adding cross-parameter 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?

States a specific verb+resource (get a swap quote for a token) and sharpens it with the scope: routes (Uniswap v2/v3/v4, Aerodrome, direct or via WETH), chains (Base, Ethereum, Arbitrum, Optimism, Polygon), and outputs (price impact, minimum received, alternatives). An agent can distinguish it from token.risk or market.snapshot 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?

"Right before an on-chain swap" gives a clear, specific usage trigger — the pre-trade check step. It does not, however, name when *not* to use it or point at sibling tools (e.g. token.risk for safety checks, decision.pre_trade for the trade decision), so routing against alternatives is left to inference.

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