Market Intelligence API

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real behavior beyond them: data is delayed at least one hour, it is a free/limited sample, and each row includes realized forward price outcomes. It does not discuss rate limits or refresh cadence, but the additions are substantive.

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 value ('FREE sample of the premium decision') followed by the payload contents, then a one-line usage cue. Dense but every clause carries information; minor wordiness in the symbol enumeration.

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 so well, enumerating the fields returned and the forward-return horizons. Missing only pagination/refresh details and explicit sibling disambiguation.

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 optional parameter at 100% schema coverage, so the baseline is 3. The description's mention of 'every symbol with live on-chain trading' plus examples reinforces the omit-to-get-all behavior, but adds no format or naming conventions 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?

States a specific verb+resource: returns the latest hourly decision (action, direction, conviction, pillar scores) per symbol, delayed an hour, with 1h/4h/24h follow-through. It distinguishes itself as the 'FREE sample' versus a paid/live version, but never names the sibling decision.lite or decision.pre_trade, so sibling routing is left implicit.

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

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

Gives a clear intended context: 'Judge the decisions before buying a live one,' which tells the agent this is an evaluation/preview tool rather than a live signal source. It stops short of explicit when-not conditions or naming the alternative live tool.

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, open-world, and non-destructive behavior. The description adds high-value context beyond that: a $0.002 cost, on-chain reads every 10 minutes, exclusion of reward tokens, and explicit sort order. It does not cover auth or rate limits, but those are less critical for a paid read 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 core purpose and remains a single dense sentence with no filler. It is appropriately sized for the number of dimensions it must cover, though the accumulation of clauses makes it slightly run-on.

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 still names the key return fields (APY, utilization, USD size), data freshness, cost, scope, and exclusions. It is nearly complete for an agent to call correctly, though it could explicitly mention how the limit parameter affects returned results.

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 80%, so the schema already does most parameter documentation. The description lists chains and protocols that map to enum parameters and mentions assets like USDC/WETH, but adds little syntax or filtering detail 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 names a specific resource (DeFi lending yields) and enumerates exactly what is returned: supply and borrow APY, utilization, USD size, chains, protocols, and sorting. It is clearly distinguishable from all sibling tools, which cover stocks, macro, news, and token-specific verdicts.

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 does not say when to use this tool versus alternatives, nor does it name any sibling tool as a routing option. Usage is only implied by the tool's data domain, leaving an agent to infer 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?

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 readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds genuinely new context: a per-call cost ($0.005), UTC timezone, and the specific calendar sources, all of which help an agent decide whether to spend the call.

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

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

Two dense sentences that front-load the returned value and sources, then close with the usage cue. No filler, though the source list is somewhat packed.

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 event categories and timezone, giving the agent a clear sense of the payload. It could say more about the response structure (e.g., per-event fields), but coverage is solid for a read-only 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?

Schema description coverage is 100% with enums and defaults documented for all three parameters, so the schema carries the load. The description adds only the implicit UTC/importance framing, not parameter-specific syntax beyond that. 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 specifically what is returned (next market-moving events in UTC with importance) and names the authoritative sources (BLS, BEA, FOMC, ECB). This differentiates it from generic news/market siblings, though it never explicitly contrasts itself with news.symbol 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?

"Check before opening a position" gives a clear, actionable context for when to call it, and the cost signal ($0.005) helps an agent weigh the call. There is no explicit exclusion or named alternative, 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 behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the data provenance (Hyperliquid prediction markets), an apparent per-call cost of $0.005, and the returned fields (24h change, volume, decision date).

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

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

A single front-loaded sentence that leads with the resource and cost before enumerating the return fields. Dense but readable; the parenthetical is the only slightly awkward element.

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 the return payload, and it does so by naming the probabilities, 24h change, volume and decision date. It is close to complete for a zero-parameter read tool, though the exact response structure remains only partially specified.

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. The description correctly implies the tool is invoked without arguments.

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 (Fed rate decision odds for the next FOMC and other central-bank decisions) and its source (Hyperliquid prediction markets), plus the shape of the answer (cut/no-change/hike probabilities). It does not explicitly differentiate itself from potentially overlapping siblings such as markets.prediction or macro.calendar, 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.

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

Usage is only implied: an agent can infer this is the tool for Fed/central-bank rate odds, but the description never states when to prefer it over macro.calendar or markets.prediction, nor any exclusion or prerequisite. Adequate but with a clear routing gap.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description still adds genuinely useful behavior beyond that: the $0.005 per-call cost, the deterministic sort order ('most traded first'), and the data source (HIP-4). It omits pagination/limit behavior, which keeps it from a 5.

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

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

Two sentences, front-loaded with the data source, cost and sort order before the content inventory and the filter hint. The middle clause is dense with a long comma-separated inventory, but every element carries selection-relevant information, so little is wasted.

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

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

With no output schema, the description usefully enumerates the returned fields (question, per-option probability, 24h change in points, 24h USDC volume) and coverage areas, so an agent knows what it will receive. Missing details such as result-count behavior for the limit parameter or error modes keep it short of 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 description coverage is 100%, so the baseline is 3. The description reinforces that filtering is by category or free text and gives example query terms in the schema itself, but it adds no format or constraint detail (e.g., limit cap of 200) beyond what the schema already documents.

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 (open prediction markets on Hyperliquid HIP-4) and enumerates exactly what each row contains: question, option probabilities, 24h point change, 24h USDC volume, plus the covered subject areas. That is far more than a restatement of the name. It stops short of explicitly distinguishing itself from adjacent siblings like macro.fed_odds or decision.pre_trade, which would be needed for 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?

'Filter by category or text' implies how to narrow results, so usage is partially inferable, but there is no statement of when to reach for this tool versus macro.fed_odds (Fed odds), market.opportunities, or the decision.* tools. No when-not guidance or alternatives are offered.

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, 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/idempotent/non-destructive/openWorld, so safety is covered. The description adds substantive behavioral context: which venues are scanned, what checks are performed (liquidity, sell simulation, v4 hook powers, first trades), and what the three verdict labels mean. It stops short of noting ordering, pagination, or freshness beyond the one-hour window.

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 scope front-loaded and the return contents enumerated after a colon; no filler. It is long, but every clause carries information the agent needs, so it stays close to maximally efficient.

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 well (verdict, liquidity, sell simulation, hook powers, first trades). It is nearly complete for a read-only discovery tool, lacking only return ordering or paging behavior.

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

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

Schema coverage is 100%, so all six parameters are already documented with defaults, ranges and enums, which sets the baseline at 3. The description reinforces the time window and the risk verdict but adds no syntax or interaction detail beyond the schema, and it does not resolve the mismatch between 'Base or Ethereum' in the prose and the arbitrum/optimism/polygon values mentioned in the chain 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?

The description states a specific verb and resource (tokens launched in the last hour) with explicit scope: Base or Ethereum, Uniswap v2/v3/v4 or Aerodrome pools against ETH/WETH/USDC. It also names what the output contains (verdicts, liquidity, sell simulation), letting an agent separate this discovery tool from token.risk or decision.pre_trade 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?

Usage is implied by the scoping language (find freshly launched tokens that have already been risk-checked), but there is no explicit when-to-use guidance, no exclusions, and no named alternative such as token.risk for a single known token. The agent must infer when this tool beats its 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description still adds substantial context: the specific checks performed (honeypot simulation, owner/proxy, mint, blacklist, tax, LP burn, flow; Solana mint/freeze authority, Token-2022 hooks, concentration) and the categorical verdict it returns.

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 purpose and usage, followed by a dense but relevant enumeration of checks and a pointer to the sibling tool. The mid-sentence check list is long, but every item carries selection value.

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 explaining the return verdict categories and the full scope of analysis per chain, which is everything an agent needs to decide whether to call 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?

Schema description coverage is 100%, so both parameters are already documented. The description restates the supported chains and the Base default plus the 'not the payment network' clarification, which is useful framing but adds little syntax or format meaning 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?

Opens with a specific verb+resource ('Due diligence before buying any token') and enumerates exactly what is inspected for EVM versus Solana mints, including the LOW_RISK/CAUTION/HIGH_RISK verdict. It is clearly distinguishable from siblings like token.swap_quote and token.new_launches.

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 states the trigger ('Use before buying a token') and names the alternative tool with its selecting condition ('for the price you would get on chain use token.swap_quote'). No inference required.

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 / destructiveHint=false, and the description reinforces this with 'Simulated, nothing executed' and discloses a concrete cost ($0.005). It also names what is returned (price impact, minimum received, alternatives), adding context beyond the annotations, though it omits rate limits or auth needs.

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 value ('how much you get now on the best route') and two sentences total, so it is efficient. It is dense with parenthetical asides (cost, routes, chains) but each clause carries information the agent needs, so no major 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 listing outputs (price impact, minimum received, alternatives), and annotations plus the 'simulated' note cover the safety profile for a read-only quote. Only error/edge behavior (e.g., no route found) is left unaddressed.

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%, giving a baseline of 3. The description adds semantic meaning: it clarifies what slippageBps governs ('minimum received at your slippage') and distinguishes chain as the token/pool network from the payment network, pushing it above baseline.

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

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

The description gives a specific action (get a swap quote) with rich scope: routes (Uniswap v2/v3/v4, Aerodrome, direct or via WETH) and chains. It clearly differentiates from adjacent tools like token.risk or token.new_launches by content, but never names a sibling explicitly, so it sits at a 4.

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 usage trigger for when to call it. It provides context but names no alternative tool and states no exclusions (e.g., no-route cases or when a pre-trade decision tool is preferable), so it is 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but there is no output schema, so the description carries the return-value burden and does so in detail: verdict enum, 0-100 score, simulated sale (honeypot), observed buy tax, liquidity, contract ownership, top three risks, oneLiner and share card. That is substantial behavioral disclosure 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?

Front-loaded with trigger phrases and the core action, then the return payload. The output enumeration is long and list-like, but every item is a distinct field the agent may need to reference since no output schema exists — minor redundancy only.

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

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

For a two-parameter read-only lookup with no output schema, the description supplies both the invocation triggers and the full return shape, plus the cost/latency comparison against token.risk. Nothing an agent needs to select or 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% and the chain enum with its 'base' default is fully documented in the schema, including the 'not the payment network' clarification. The description restates the same defaults and supported chains without adding format or semantic detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource: it takes a token contract address (or Solana mint) and returns a risk verdict with a defined enum of outcomes. It explicitly distinguishes itself from the sibling token.risk by being 'cheaper and shorter', so an agent can route between the two 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?

Opens with the exact user phrasings that should trigger it ('is this token safe?', 'is it a rug or a honeypot?', 'check this CA', 'can I sell it?'), then gives the routing rule: 'Use for a quick safe-to-buy answer; for every check behind it use token.risk.' Both the when and the when-to-use-the-alternative are explicit.

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