Compact 18-tool x402 market data server: token safety, Fed odds, DeFi yields, swap quotes, decisions
Scored across 18 tools
The tool set has several closely related families (decision.lite/pre_trade/sample, token.risk/verdict, market.summary/opportunities), but each description explicitly clarifies when to use one over the other, making them mostly distinguishable. Minor overlap remains that could cause misselection if descriptions are not read carefully.
Nearly all tools follow a clear category.tool pattern (e.g., market.snapshot, token.risk, macro.calendar), but there is a singular/plural inconsistency between 'market.*' and 'markets.prediction'. The deviation is minor and still readable.
18 tools is on the heavy side for a single server, falling into the 16-25 borderline range. While each tool targets a distinct product or data endpoint, the set is large enough to feel heavy and could benefit from consolidation or clearer grouping.
The surface covers a broad market-intelligence domain: decisions, macro events, prediction markets, news, fundamentals, token safety, swap quotes, DeFi yields, and market scans. Minor gaps exist, such as historical OHLCV data or explicit order-book depth, but core workflows are well supported.
Cheap live decision ($0.05): action (STRONG_BUY..STRONG_SELL), direction, conviction, a GO/WAIT answer for a side, the stance of each pillar and the measured hit rate. Same engine as get_decision on the full server /mcp ($1), without the trade plan, execution check, evidence and risks. Use as the default decision; decision.pre_trade answers only go/no-go timing for a side, decision.sample is free but an hour old.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | Optional: answers GO / GO_SMALL / WAIT / NO_GO for this side | |
| symbol | Yes | Crypto pair (ETHUSD), US ticker (NVDA) or ISIN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on non-annotation facts an agent actually needs: the $0.05 price, the explicit scope reduction versus the $1 full-server get_decision, and the staleness caveat for the free sample. It stops short of latency/rate-limit detail, so it lands just under 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?
Dense but front-loaded with the two highest-value facts (cheap, live) and the output inventory, and every sentence carries information. The single run-on paragraph with a long comma-list of outputs is slightly harder to scan than it needs to be, costing it a point.
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 itself and does so by enumerating the fields returned. With pricing, scope, sibling routing, and output contents all present, 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% with only two params, so the schema already documents symbol formats (pair/ticker/ISIN) and the side enum. The description only echoes the side semantics that the schema already states, adding no format or constraint detail. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource ('live decision') and enumerates the exact payload the agent gets back (action, direction, conviction, side GO/WAIT, pillar stances, hit rate). It also names the sibling it is a cheaper variant of (get_decision) and spells out the delta (no trade plan, execution check, evidence, risks), so an agent can distinguish it from every neighbor.
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 prescribes the default ('Use as the default decision') and routes two alternatives with their selection conditions: decision.pre_trade for side-specific timing only, decision.sample as the free-but-stale option. When/when-not/alternative coverage is essentially complete for the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Right before a trade: 'I want to buy (or sell) SYMBOL - is now a good moment?'. Returns a verdict (FAVORABLE, CAUTION, UNFAVORABLE), a score and the checks behind it: order flow, momentum, volatility, adverse events, market regime and news/filings of the last 24h. Use when you already know the symbol and side and only need go/no-go timing; for an action with conviction use decision.lite.
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | The side you intend to trade: buy or sell | buy |
| symbol | Yes | e.g. ETHUSD, BTCUSD, NVDA, TSLA | |
| window | No | Aggregation window of the live trade buckets: 1m, 5m (default) or 15m | 5m |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, open-world). The description goes beyond them by disclosing the return shape (verdict, score, underlying checks) and the concrete data sources consulted (order flow, momentum, volatility, adverse events, regime, 24h news/filings). It omits latency/cost limits, 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 real-world scenario, then the return payload, then the alternative-tool routing - each sentence earns its place. Slightly dense, but 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 present, the description carries the return-value burden and does so by enumerating the verdict, score and checks. Complete for a read-only timing tool; minor gaps like latency or pagination are not material here.
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 side, symbol and window are already documented in the schema; the description adds no parameter syntax or constraints beyond the schema's own descriptions. Per the high-coverage baseline, 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: evaluates whether now is a good moment to trade a given symbol/side, returning a FAVORABLE/CAUTION/UNFAVORABLE verdict. It explicitly disambiguates from its sibling decision.lite, so an agent can choose between them 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?
States the exact triggering context ('when you already know the symbol and side and only need go/no-go timing') and names the alternative with its own condition ('for an action with conviction use decision.lite'). When-to-use and the sibling route are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE sample of the premium decision: the latest hourly decision (action, direction, conviction, pillar scores) of every symbol with live on-chain trading (e.g. ETHUSD, BTCUSD, NVDA, TSLA, SPY, AAPL), delayed at least an hour, with what the price did 1h/4h/24h later. Judge the decisions before buying a live one.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Optional; omit for all ten symbols |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema behavior: the data is delayed at least one hour, it is a free sample of a premium product, and it includes realized 1h/4h/24h price outcomes. That delay disclosure is exactly the kind of trait annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence, front-loaded with the value proposition ('FREE sample') and ending on the actionable hook. Every clause carries information; only the long example-symbol list is mildly padded, and there is no wasted framing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of describing return fields and the price-followup columns, and the annotations carry the safety profile. An agent can call this correctly with zero required params, though the relationship to the other decision.* tiers remains ambiguous.
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 sole optional symbol parameter is fully documented there ('omit for all ten symbols'). The description restates the symbol universe with examples (ETHUSD, BTCUSD, NVDA...) but adds no syntax, format, or defaulting behavior 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 resource (latest hourly decision per symbol) and enumerates the returned fields (action, direction, conviction, pillar scores) plus the follow-up price data. It frames itself as the 'FREE sample' of a premium decision, which hints at a paid tier, but never names the sibling tools (decision.lite, decision.pre_trade) it must be chosen over.
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 line 'Judge the decisions before buying a live one' implies the evaluation/trial use case, but there is no explicit when-to-use versus alternatives such as decision.lite or decision.pre_trade, and no statement of when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DeFi lending yields ($0.002): supply and borrow APY, utilization and USD size of every Aave v3 (Ethereum, Base, Arbitrum, Optimism, Polygon), Spark and Compound v3 market, read on chain every 10 minutes, highest supply APY first, with the best USDC, USDT, WETH, WBTC and DAI rate. Base yield only (no reward tokens).
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Token symbol (USDC, WETH, ...) or stablecoins for every stablecoin; omit for all | |
| chain | No | Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed). Not the payment network | |
| limit | No | Maximum number of results | |
| protocol | No | ||
| minTvlUsd | No | Leave out markets with less supplied |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive. The description adds valuable context beyond them: a $0.002 cost, 10-minute on-chain refresh cadence, base-yield-only scope, and result ordering. This is solid behavioral detail layered on top of the safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads purpose, price and sort order, with no filler sentences. It is somewhat crammed with parenthetical lists, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned fields (supply/borrow APY, utilization, USD size), the sort order and refresh cadence. It is nearly complete for an agent to invoke and interpret results, though it could clarify parameter interactions (e.g. asset vs chain defaults).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the schema already documents asset, chain, limit, protocol and minTvlUsd. The description echoes example assets and chains but adds no syntax or semantics beyond what the schema provides. Baseline 3 applies when structured data 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?
States a precise resource (DeFi lending yields) with the exact metrics returned (supply/borrow APY, utilization, USD size), the protocols (Aave v3, Spark, Compound v3) and chains covered. No sibling tool overlaps this domain, so differentiation is inherent.
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 (finding the best supply rate for major assets) and notes scope limits ('base yield only, no reward tokens'), but gives no explicit when-to-use/when-not guidance or alternatives. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE: tell the operator what was missing or wrong (a route or tool you expected, a symbol without data, a confusing parameter). Read by a human; it decides the next routes.
| Name | Required | Description | Default |
|---|---|---|---|
| route | No | Route or tool it is about (optional) | |
| rating | No | Optional 1-5 rating of the route or tool | |
| message | No | Anything else, up to 1000 characters | |
| missing | No | What you needed and did not find |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, openWorld. The description adds genuinely new behavioral context: it is free of cost, it is read by a human rather than processed automatically, and it influences future routes. It does not say whether a reply is ever returned or how the message is stored, 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?
A single sentence with a front-loaded 'FREE' qualifier and a compact parenthetical of concrete examples. Every clause earns its place; nothing is redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter, no-output-schema tool, the description covers purpose, cost, and the human consumption model. It leaves open whether the agent should expect any acknowledgement or follow-up, which is a minor but real omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so route, rating, message, and missing are all documented in the schema itself. The description reinforces what the payload should contain but adds no format, length, or mutual-exclusivity 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 concrete verb+resource (send feedback to the operator) and immediately enumerates the kinds of input it expects: a missing route/tool, a symbol without data, a confusing parameter. Nothing in the sibling list (all analytics/decision tools) could be confused with this channel.
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 makes the trigger condition clear (tell the operator what was missing or wrong) and flags that it is FREE, which encourages use. There are no sibling alternatives to route between and no exclusions are stated, so the only gap is the absence of explicit 'do not use this for X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Next market-moving events ($0.005) in UTC with importance, from official calendars: US CPI, jobs report, PCE, GDP, PPI, JOLTS (BLS, BEA), FOMC and ECB rate decisions. Check before opening a position.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to cover (look-back; days ahead for calendars) | |
| region | No | Region: all, us or eu | all |
| importance | No | Minimum importance of the events to include | medium |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful behavioral context beyond annotations: timezone (UTC), official data sources, event importance, and a cost indicator ($0.005). Annotations already cover read-only, idempotent, non-destructive safety, so this is solid additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core purpose and a concrete usage instruction. The event list is long but earns its place by making the tool's scope unambiguous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and strong annotations, the description is nearly complete for a low-complexity calendar tool. It could say more about return shape, but an output schema is absent and the event data is sufficiently characterized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters including enums. The description reinforces importance and timezone but does not add much parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the resource (market-moving macro events) and scope (next events, UTC, with importance, from official calendars), with concrete event examples. It is distinguishable from siblings like macro.fed_odds, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage context: 'Check before opening a position.' It does not state when not to use it or name an alternative sibling, but the intended timing is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fed rate decision odds ($0.005): probability of a cut, no change or a hike at the next FOMC and other central-bank decisions, from Hyperliquid prediction markets, with 24h change, volume and the decision date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 genuinely new context: the data source is Hyperliquid prediction markets, the call costs $0.005, and the payload includes 24h change, volume and decision date. Freshness/pagination behavior is still unspecified, hence 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?
A single front-loaded sentence that leads with the resource and scope, then layers source, cost and returned fields without filler. 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?
With no output schema, the description does useful work by enumerating the returned signals (probabilities, 24h change, volume, decision date) and the upstream source. It stops short of describing the response shape or update cadence, which would fully close the gap for a no-param data 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?
There are zero parameters, so the schema provides nothing for the description to compensate for and the baseline is 4. The description correctly spends no words on inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and verb-equivalent ('Fed rate decision odds') and enumerates exactly what is reported: cut/no-change/hike probabilities for the next FOMC and other central-bank decisions. It implicitly distinguishes itself from macro.calendar (event listings) and markets.prediction (general prediction markets), but never names a sibling, so routing is left partly to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the subject matter: an agent can guess this is for macro rate-expectation questions, but there is no explicit 'use this when…' or exclusion versus macro.calendar or markets.prediction. No prerequisites or rate-limit guidance either.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Why is a symbol moving? ($0.02) The 15-minute move and its likely drivers from every source (on-chain flow, unusual activity, smart money, perp crowding, 48h news, SEC filings, insiders) with direction and weight, plus a one-sentence summary. Crypto, tokenized stocks and US stocks.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | e.g. ETHUSD, NVDA, TSLA |
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 meaningful context on top: a stated cost ($0.02) and a clear inventory of what the response contains (drivers with direction and weight, plus a one-sentence summary). It stops short of disclosing freshness/caching behavior or any rate/credit limits for repeated calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the question the tool answers and the price, then a single dense sentence enumerating sources and output shape. Every clause carries information; nothing is redundant with the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing the return and does so concretely (15-minute move, per-source drivers with direction and weight, one-sentence summary) plus asset coverage and cost. Minor gaps remain: no statement of data freshness/latency or what happens for illiquid/unsupported symbols.
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, and the schema documents it at 100% coverage with examples (ETHUSD, NVDA, TSLA). The description still adds value by naming the accepted asset universes (crypto, tokenized stocks, US stocks), which tells the agent the symbol namespace is cross-asset rather than crypto-only.
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 framed question ('Why is a symbol moving?') and states exactly what is produced: the 15-minute move plus its likely drivers broken out by source (on-chain flow, unusual activity, smart money, perp crowding, news, SEC filings, insiders). An agent can distinguish this diagnostic/attribution tool from data-dump siblings like market.snapshot or market.summary 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?
The 'Why is a symbol moving?' framing implies when to reach for it, and asset coverage ('Crypto, tokenized stocks and US stocks') is stated, which helps route requests. However, there is no explicit when-not guidance, no mention of alternatives (e.g. market.summary for a plain price recap), and no note on the 15-minute window being the fixed horizon versus longer-horizon tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Goal-driven scan: name an objective and constraints, get ranked symbols with supporting and conflicting evidence grouped by independent source (spot DEX flow, perp positioning, smart-money wallets), typed risk factors, data quality, the live 1h hit rate of the signal and the next calls to make. Use instead of chaining screeners. Objectives: unusual_buying, unusual_selling, breakout, breakdown, crowded_positioning, smart_money_accumulation, smart_money_distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Aggregation window of the live trade buckets: 1m, 5m (default) or 15m | 5m |
| include | No | Blocks to return; default all | |
| universe | No | Symbols to scan (max 100); omit for all covered symbols | |
| objective | Yes | What to look for | |
| assetClass | No | Restrict to crypto, us_equity or perp_only symbols | |
| maxResults | No | Maximum number of ranked symbols (default 10) | |
| minVolumeUsd | No | USD traded in the window | |
| minConfidence | No | Minimum signal confidence, 0-100 | |
| minBuyPressure | No | Pressure on the objective's side (buy for buying, sell for selling) | |
| minVolumeMultiple | No | Volume vs the symbol's own baseline | |
| minIndependentSources | No | Distinct sources confirming the direction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful output context: ranked symbols with supporting/conflicting evidence grouped by independent source, typed risk factors, data quality, live 1h hit rate, and next calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is dense but front-loads purpose and outputs, followed by a useful alternative-use sentence and the objective list. It could be split for readability but contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns, and it lists the returned blocks (evidence, risk factors, quality, track record, next calls). It omits fine-grained response structure, but is complete enough for a scan tool with rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters are fully documented in the schema. The description adds little beyond repeating the objective enum and mentioning constraints/grouping by source, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (scan) and resource (ranked symbols) with a clear goal-driven scope, and notes it replaces chaining screeners. Does not explicitly name a sibling tool, but the objective-driven scan is clearly distinguishable from snapshot/summary tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use instead of chaining screeners,' providing an alternative workflow, and instructs to name an objective and constraints. Lacks when-not conditions or direct comparison to sibling decision tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cheapest call ($0.001): headline numbers of one symbol right now: price, change, buy pressure, signal, event, confidence and trade count.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | e.g. ETHUSD, BTCUSD, NVDA, TSLA | |
| window | No | Aggregation window of the live trade buckets: 1m, 5m (default) or 15m | 5m |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new context beyond them: the price point ($0.001) and the fact that it reflects the state 'right now', which helps an agent judge cost and freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the cost hook front-loaded and the returned fields following. Every clause carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by enumerating the fields returned (price, change, buy pressure, signal, event, confidence, trade count). Combined with read-only annotations and full schema coverage, an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both symbol and window (with enum and default) are already fully documented in the schema. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('headline numbers of one symbol right now') and enumerates the returned fields, so the agent knows exactly what it gets. It does not, however, explicitly differentiate itself from the sibling market.summary, which likely returns overlapping headline metrics.
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)' and 'right now' imply a cost-conscious, single-symbol, real-time use case, which hints at selection criteria. But no alternative is named and there is no explicit when-to-use / when-not-to-use guidance versus market.summary or news.symbol.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prediction markets live from Hyperliquid HIP-4 ($0.005): every open market as a plain question with each option's probability, 24h change in points and 24h USDC volume, most traded first: crypto and stock price targets, Fed and central-bank rate decisions, IPOs (Anthropic, OpenAI), sports and awards. Filter by category or text.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Text to find in the question or options, e.g. BTC, FOMC, Anthropic | |
| limit | No | Maximum number of results | |
| category | No | News category; omit for all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real value beyond that: the upstream source (Hyperliquid HIP-4), the per-call price ($0.005), the sort order (most traded first), and the returned fields. It stops short of stating freshness/latency or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense but well-ordered sentence: source and cost first, then row shape and sort order, then filtering. No filler sentences and nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of describing return values, and it does so concretely (question, per-option probability, 24h change in points, 24h USDC volume, sort order) plus the data source. 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 the enum values, default limit, and max are already documented in the schema; baseline is 3. The description's 'filter by category or text' merely restates the two filters without adding syntax, matching rules, or edge cases 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?
Specific verb+resource: it lists live prediction markets from a named source (Hyperliquid HIP-4) and describes the exact shape of each row (question, option probabilities, 24h point change, 24h USDC volume, sorted by volume). An agent can distinguish it from neighbors like macro.fed_odds or market.opportunities 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?
The closing 'Filter by category or text' implies how to narrow results, but there is no explicit when-to-use guidance, no when-not, and no routing to or away from adjacent siblings such as macro.fed_odds (Fed odds) or market.opportunities. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get market-wide breadth, buying pressure, momentum, unusual activity and data freshness. Use for breadth, regime and the top movers in one call; for a goal-driven scan use market.opportunities.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | Aggregation window of the live trade buckets: 1m, 5m (default) or 15m | 5m |
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 bar is lower. The description adds what the payload actually contains — breadth, buying pressure, momentum, unusual activity, data freshness — which is meaningful since no output schema exists.
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, and the content summary is front-loaded ahead of the routing hint. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned dimensions and signaling data freshness. Combined with annotations covering the read-only/idempotent profile and the routing to market.opportunities, an agent has everything needed to 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 description coverage is 100% and the single window parameter is fully documented in the schema, including its enum and default. The description adds no syntax or interpretation guidance for window, 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 ("Get") and a concrete resource set: market-wide breadth, buying pressure, momentum, unusual activity and data freshness. It names the sibling it is not (market.opportunities), so an agent can separate 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?
"Use for breadth, regime and the top movers in one call" gives an explicit when-to-use, and "for a goal-driven scan use market.opportunities" names the alternative with the condition that selects it. It stops short of stating exclusions (e.g., single-symbol or historical use cases).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
News for one symbol ($0.003): headlines and SEC filing events tagged with the ticker (e.g. NVDA, ETHUSD), newest first, with publisher attribution, sentiment and an event type and materiality where classified.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results | |
| symbol | Yes | Ticker or crypto pair, e.g. NVDA, TSLA, ETHUSD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), but the description adds genuinely new behavioral facts: a per-call cost of $0.003 and a newest-first ordering guarantee, plus disclosure that sentiment/event type/materiality are only present 'where classified'. Pagination/rate-limit behavior is not mentioned beyond the limit parameter.
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 resource and scope front-loaded, followed by cost and result composition. Every clause carries information and nothing is repeated.
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 appropriately describes the return contents (headlines, SEC filing events, publisher attribution, sentiment, event type, materiality) and ordering. Cost and the conditional nature of some fields are covered; only edge behavior (unknown symbol, result exhaustion) is 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% and both parameters are already documented with examples (NVDA, TSLA, ETHUSD) and bounds, so the schema does the heavy lifting. The description restates the ticker format examples rather than adding new semantics, landing at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource and its scope precisely: news for exactly one symbol, comprising headlines plus SEC filing events tagged with the ticker. Content details (attribution, sentiment, event type, materiality) make the output shape predictable. No sibling tool covers news, so explicit differentiation isn't required, keeping this just 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?
The single-symbol scope is stated, which implicitly tells the agent this is the per-ticker news lookup, but there is no explicit when-to-use guidance, no conditions, and no named alternative for broader news coverage. Usage must be inferred from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fundamentals of up to 10 US-listed companies in one call ($0.03): per ticker revenue, earnings, margins, growth, balance sheet and a fundamental signal from SEC filings.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | US tickers, e.g. ["AAPL", "MSFT"] |
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 context the annotations cannot: the $0.03 cost per call and the SEC-filings data source. It stops short of noting latency or coverage limitations.
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 core capability, then the batch limit and cost, then the returned payload. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the return fields (revenue, earnings, margins, growth, balance sheet, signal), and it discloses the cost and ticker scope. An agent has everything needed to 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% and only one parameter exists, so the schema carries the basic load (maxItems 10, example tickers). The description adds the non-obvious constraint that symbols must be US-listed, which meaningfully narrows valid input beyond the schema's plain string array.
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 (fetch fundamentals), resource (US-listed company fundamentals), and scope (up to 10 tickers in one call), then enumerates the returned fields. No sibling tool overlaps this space, so the agent can select it unambiguously.
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 batch framing ('up to 10 companies in one call'), but there is no explicit when-to-use statement, no exclusions, and no reference to any alternative among the sibling tools. Minimum viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tokens launched in the last hour on Base or Ethereum, already risk-checked: every new Uniswap v2/v3/v4 or Aerodrome pool against ETH, WETH or USDC with liquidity, sell simulation, v4 hook powers, first trades and a verdict (LOW_RISK, CAUTION, HIGH_RISK).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed). Not the payment network | base |
| limit | No | Maximum number of results | |
| minutes | No | Look-back for new pools in minutes (default 60) | |
| verdict | No | Keep only tokens with this risk verdict: LOW_RISK, CAUTION or HIGH_RISK | |
| minLiquidityUsd | No | Minimum pool liquidity in USD | |
| includeEstablished | No | Also list new pools of tokens that already existed a day earlier (new markets, not launches) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description still adds real value by disclosing what is actually performed: sell simulation, v4 hook power checks, first trades, liquidity, and a three-level verdict. It does not say whether results are cached or how fresh the underlying data is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence, front-loaded with the core scope before the supporting detail. It is slightly over-packed with the enumeration of pool sources and checks, but every clause carries substantive 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 usefully enumerates the return payload (liquidity, sell simulation, hook powers, first trades, verdict). The remaining gaps are the chain-coverage inconsistency with the schema and the absence of guidance on when to prefer token.risk or token.verdict, which keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are documented in the schema, setting the baseline at 3. The description adds only the default window ('last hour'), and it actually narrows the chain scope to Base or Ethereum while the schema's chain enum description mentions arbitrum, optimism, polygon and solana, leaving the true supported set ambiguous.
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 ('Tokens launched in the last hour on Base or Ethereum') plus the exact pool types and chains scanned, so an agent knows this is a new-launch discovery feed. It does not explicitly distinguish itself from siblings like token.risk or token.verdict, which also involve risk verdicts, so an agent must infer that this is the discovery counterpart.
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 scope ('tokens launched in the last hour'), suggesting it fits fresh-launch screening. There is no explicit when-to-use, no exclusions, and no routing to token.risk or token.verdict for already-known tokens. The inclusion of 'includeEstablished' in the schema hints at a boundary with established tokens, but the description never states it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Due diligence before buying any token (Base by default; also ethereum, arbitrum, optimism, polygon, solana). EVM: simulated sell and buy (honeypot check), owner and upgradeable proxy, mint, blacklist, pause and fee functions, liquidity, LP burn, observed buy tax, last-hour flow. Solana mints: mint and freeze authority, Token-2022 transfer fee, permanent delegate, transfer hook, pause and top-wallet concentration. Verdict LOW_RISK, CAUTION or HIGH_RISK. Use before buying a token; for the price you would get on chain use token.swap_quote.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed). Not the payment network | base |
| address | Yes | 0x-prefixed ERC-20 contract, or a base58 Solana mint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real behavioral value beyond that by enumerating the concrete checks performed (honeypot simulation, mint/blacklist/pause/fee functions, LP burn, flow) and the three verdict values returned. It stops short of noting latency, caching or rate limits, which keeps it off 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-loaded with the core purpose and the preventive use case, followed by a dense but purposeful checklist of what is verified and the verdict taxonomy. The EVM/Solana enumerations are list-heavy but each item carries signal; no sentence is pure filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only risk tool with no output schema, the description supplies the outcome vocabulary (LOW_RISK, CAUTION, HIGH_RISK) and the scope of analysis per chain family, which is enough to interpret results. It lacks only secondary detail like latency or result caching, which is minor for this tool class.
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 chain enum duplicates the listed networks in the description. The description adds only the default-chain emphasis ('Base by default'), which the schema already encodes as default: base. Baseline 3 is appropriate 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 states a specific action (due diligence / risk assessment) on a specific resource (a token) and enumerates exactly what is inspected for EVM and Solana. It also differentiates itself from the sibling token.swap_quote by assigning pricing to that tool, 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?
It gives an explicit trigger ('Use before buying a token') and names the alternative with the condition that selects it ('for the price you would get on chain use token.swap_quote'). Nothing about when-to-use 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.
Right before an on-chain swap ($0.005): how much you get now on the best route (Uniswap v2/v3/v4, Aerodrome, direct or through WETH) on Base, Ethereum, Arbitrum, Optimism or Polygon, with price impact, minimum received at your slippage and alternatives. Simulated, nothing executed.
| Name | Required | Description | Default |
|---|---|---|---|
| buy | Yes | ETH, WETH, USDC or a 0x token address | |
| sell | Yes | ETH, WETH, USDC or a 0x token address | |
| chain | No | Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed). Not the payment network | base |
| amount | Yes | Sell amount in whole units, e.g. 1000 | |
| slippageBps | No | Slippage tolerance for the minimum received, in basis points |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds useful context beyond annotations: the quote costs $0.005, is simulated, covers multiple venues and chains, and returns price impact, minimum received, and alternatives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It front-loads the timing and cost, then efficiently packs route scope and return details into one sentence plus a short simulation disclaimer. There is no redundant restatement of the tool name or schema.
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?
Although there is no output schema, the description enumerates the key returned elements: how much you get, price impact, minimum received at your slippage, and alternatives. Given the rich annotations and full schema coverage, this is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents sell, buy, amount, chain, and slippageBps. The description restates supported chains and slippage concepts but adds little parameter-specific syntax beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: quote how much you get now for an on-chain swap, naming route venues, supported chains, price impact, minimum received, and alternatives. It also distinguishes the tool from execution by saying it is simulated and nothing is executed.
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 signals timing with "Right before an on-chain swap" and clarifies that the operation is simulated, not executed. However, it does not name sibling tools or explicitly state when not to use this quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks "is this token safe?", "is it a rug or a honeypot?", "check this CA" or "can I sell it?". Send a token contract address (Base by default; also ethereum, arbitrum, optimism, polygon, or a Solana mint), get a short verdict: LOW_RISK, CAUTION or HIGH_RISK, a 0-100 safety score, one plain-language sentence, whether a simulated sale succeeds (honeypot check), observed buy tax, liquidity, who controls the contract, the top three risks, a oneLiner to quote and a share card. Cheaper and shorter than token.risk. Use for a quick safe-to-buy answer; for every check behind it use token.risk.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed). Not the payment network | base |
| address | Yes | 0x-prefixed ERC-20 contract, or a base58 Solana mint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. With no output schema, the description usefully discloses the returned shape (verdict, score, simulated-sale honeypot check, buy tax, controller, top risks, share card) and that it is deliberately cheaper and shorter than token.risk. It does not mention auth needs or rate/latency limits, keeping it just 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?
Front-loaded with trigger phrases, then inputs, then outputs, then sibling routing — every sentence earns its place. It is dense and runs as one long sentence, which costs some readability, but 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?
For a two-parameter tool with no output schema, the description fully carries the return-value burden, enumerating every field an agent would need to interpret or quote, plus the sibling routing. Nothing required to call or use 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 coverage is 100%, so both parameters are already documented, including the chain enum, the base default, and the address format. The description restates the same chain list and address format without adding syntax or edge-case meaning 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?
States a specific verb+resource (send a token contract address, get a verdict) and enumerates the concrete outputs: LOW_RISK/CAUTION/HIGH_RISK, safety score, honeypot simulation, buy tax, liquidity. It explicitly distinguishes itself from the sibling token.risk in both scope and cost.
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 explicit trigger phrasings ("is this token safe?", "is it a rug or a honeypot?", "check this CA") and names the alternative with the condition that selects it: "for every check behind it use token.risk." When-to-use and when-to-use-something-else are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
decision.pre_trade1 field changedInput schema / properties / window / enumPrevious value: -[
- "1m",
- "5m",
- "15m"
-]New value: +[
+ "1m",
+ "5m",
+ "15m",
+ "1h",
+ "4h",
+ "24h"
+]market.opportunities1 field changedInput schema / properties / window / enumPrevious value: -[
- "1m",
- "5m",
- "15m"
-]New value: +[
+ "1m",
+ "5m",
+ "15m",
+ "1h",
+ "4h",
+ "24h"
+]market.snapshot1 field changedInput schema / properties / window / enumPrevious value: -[
- "1m",
- "5m",
- "15m"
-]New value: +[
+ "1m",
+ "5m",
+ "15m",
+ "1h",
+ "4h",
+ "24h"
+]market.summary1 field changedInput schema / properties / window / enumPrevious value: -[
- "1m",
- "5m",
- "15m"
-]New value: +[
+ "1m",
+ "5m",
+ "15m",
+ "1h",
+ "4h",
+ "24h"
+]defi.yieldsmacro.fed_oddsmarkets.predictionsignals.track_recordtoken.verdicttoken.new_launches1 field changedInput schema / properties / chain / descriptionPrevious value: -"Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed)"New value: +"Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed). Not the payment network"token.risk1 field changedInput schema / properties / chain / descriptionPrevious value: -"Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed)"New value: +"Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed). Not the payment network"token.swap_quote1 field changedInput schema / properties / chain / descriptionPrevious value: -"Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed)"New value: +"Chain of the token or pool: base (default), ethereum, arbitrum, optimism or polygon (solana where listed). Not the payment network"decision.litedecision.pre_tradedecision.samplefeedback.sendmacro.calendarmarket.explain_movemarket.opportunitiesmarket.snapshotmarket.summarynews.symbolsignals.track_recordstocks.fundamentalstoken.new_launchestoken.risktoken.swap_quotePay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Pay-per-call ($0.005-$0.03 USDC) market, on-chain, and prediction-market data API for AI agents and trading bots via x402 — no signup, no API key. Remote MCP server, 28 tools: token security (honeypot/liquidity/counterfeit checks), Hyperliquid oracle-gap risk, kimchi premium, funding APR, DEX slippage, Polymarket arbitrage/liquidity audits, Hyperliquid HIP-4 odds.
Market data, LLM gateway, ML forecasts, batch+bundle, self-building catalog. USDC via x402 + MPP.
x402-payable on-chain forensics tools: token verdicts, settle-safe RWA screens, wallet trust screens
Add one secure layer between your agents and this server.
