Prediction-market quotes, fill estimates and odds trends, paid per call with x402 USDC on Base.
Scored across 6 tools
Most tools are clearly distinct: search_markets finds markets, get_quote returns a book snapshot, estimate_fill simulates a sized buy, get_status reports agent health, and the two trends tools separate raw snapshots from aggregates. The only mild overlap is between get_quote and estimate_fill, since both surface pricing/depth information, but the sizing/slippage framing of estimate_fill keeps them separable.
All names use a consistent snake_case verb_noun pattern (search_markets, get_quote, get_status, estimate_fill, get_odds_trends, get_odds_trends_summary). The get_odds_trends / get_odds_trends_summary pair follows a predictable prefix-nesting convention that reinforces rather than breaks the pattern.
Six tools is well within the sweet spot and each maps to a distinct step in the arbitrage workflow: discovery, quoting, fill sizing, trend history, trend aggregation, and health. No tool feels redundant or padding.
The surface covers market discovery, pricing, fill estimation, and trend analysis, but an arbitrage agent has no way to place/cancel orders or inspect account balance, positions, and open exposure — get_status explicitly returns no account data. These are notable gaps that would force an agent to dead-end at execution and portfolio management.
Fill estimate for buying a number of shares of one outcome: VWAP, total cost and partial-fill status within a slippage cap. $0.01 USDC per call on Base. Not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| shares | Yes | ||
| token_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden, and it does disclose real behavior: a $0.01 USDC charge per call on Base is a paid-call/auth constraint an agent must know before invoking, and the slippage cap bounds the result. It still never states that the call is read-only and places no order, nor any rate or failure 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 densely packed sentence front-loads the core purpose, then lists outputs, pricing, and a disclaimer. No filler; the only slightly off-topic element is the 'Not advice' boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The enumeration of return values compensates for the absent output schema, and the cost line covers the missing annotations. But with no annotations, no output schema, and 0% parameter documentation, the undescribed token_id and the unstated read-only/no-order-placed nature leave the definition short of 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 0%, so the description must document both parameters and largely does not: 'shares' is clarified as a share count of one outcome, but token_id is never explained (identifier of which outcome, in what format). The agent is left to infer the key input from the phrase 'one outcome'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Fill estimate for buying a number of shares of one outcome') and names the three quantities returned (VWAP, total cost, partial-fill status). It is clear on its own, but does not explicitly contrast itself with the sibling get_quote, which is the most likely point of confusion.
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?
'For buying' implicitly scopes the tool to buy-side, pre-trade estimation rather than selling or post-trade checks, and the slippage cap indicates it is a what-if calculation. However, no alternative is named and there is no explicit when-to-use/when-not statement relative to get_quote or get_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stored odds-comparison snapshots from the arbitrage worker for trend analysis. $0.01 USDC per call on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| team | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The pricing note ('$0.01 USDC per call on Base') is a genuinely valuable disclosure about cost and payment network, but nothing explains pagination behavior for the limit parameter, how records are ordered, or what happens when no snapshots exist for the range.
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 with no filler, and the data-source identification is front-loaded ahead of the pricing note. It is efficient, though efficiency here partly reflects under-specification rather than economy.
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 three-parameter, zero-coverage, annotation-free, output-schema-free tool, the description is far too thin. It covers provenance and cost but leaves the entire parameter surface and return shape unexplained, so an agent has no basis for choosing values or interpreting 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 0% and the description says nothing about days, team, or limit. The three parameters — including a team filter and a result cap — are completely undocumented in both structured and unstructured fields, so an agent must guess at their semantics and interaction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (stored odds-comparison snapshots from the arbitrage worker) and an implied purpose (trend analysis), but it is a noun phrase rather than a verb+resource statement and never clarifies how it differs from its sibling get_odds_trends_summary. An agent can guess it retrieves historical odds data, but the boundary with the summary tool is left ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus get_odds_trends_summary, search_markets, or get_quote. 'For trend analysis' hints at a use case but gives no conditions, exclusions, or alternative routing, which matters given a near-identical sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregated edge trends per event from stored snapshots: min/max/avg taker edge and best expected maker edge. $0.01 USDC per call on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add meaningful behavioral context: data comes from 'stored snapshots' and costs '$0.01 USDC per call on Base'. It does not explicitly state read-only safety, auth/payment mechanics, rate limits, or data freshness beyond 'stored snapshots'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences: the purpose and output metrics are front-loaded, and the cost is appended without waste. Every phrase carries useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the core purpose, output metrics, data source, and cost, which is enough to understand the tool at a high level. However, for a paid tool with no output schema and 0% parameter description coverage, it omits how 'days' and 'limit' behave and does not describe the response shape beyond naming the metrics.
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 0% for the two parameters 'days' and 'limit', and the description provides no information about either. It neither explains the time window semantics nor what the limit applies to, so it does not compensate for the schema gap.
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 clear resource and aggregation scope: 'Aggregated edge trends per event from stored snapshots' with specific metrics like min/max/avg taker edge and best expected maker edge. It implicitly distinguishes itself from the raw sibling get_odds_trends via 'summary' and 'aggregated', but it never explicitly names or routes between the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this summary instead of get_odds_trends, estimate_fill, or other siblings. An agent can infer it is for aggregated overviews, but no alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order-book quote for one outcome: best bid and ask, mid, spread and top five levels of depth. $0.005 USDC per call on Base. Live data, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it discloses a per-call cost of $0.005 USDC on Base, states the data is live, and adds a "not advice" disclaimer. It omits auth requirements, rate limits, and caching/latency behavior, which keeps it below 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?
Three tight sentences, each earning its place: return contents first, then cost, then data-freshness caveat. Front-loaded and free of 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 one-parameter read tool with no output schema, the description covers what is returned, cost, and data recency — enough to call it correctly. The remaining gap is how to source a valid token_id, which is the one thing an agent could still get wrong.
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 0%, so the description must compensate for the single undocumented token_id parameter. It only implies that the argument identifies "one outcome" — it never states the token_id format, that it must come from search_markets, or what happens with an invalid/unknown id.
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 verb+resource ("Order-book quote for one outcome") and enumerates exactly what it returns: best bid/ask, mid, spread, and top five depth levels. This clearly separates it from estimate_fill, though it never names a sibling to reinforce the distinction.
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 a current single-outcome price snapshot, but there is no explicit when-to-use, when-not, or pointer to estimate_fill/search_markets as the alternative path when a fill simulation or market lookup is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free: agent status, trading mode and kill-switch state. No account data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It usefully discloses cost ('Free') and data exposure ('No account data'), which tells the agent no auth/account is needed and there is no billing risk. It does not state read-only semantics explicitly, rate limits, or freshness/caching of the reported state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary content and the cost signal. Every clause earns its place; only the leading 'Free:' fragment reads slightly like a label rather than prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must hint at returns — it does by naming the three state fields. For a zero-parameter read tool with no annotations this is nearly sufficient; only freshness and read-only guarantees are unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so there is nothing to document; baseline 4 applies. The description does not need to explain any inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (get_status) and enumerates the returned facts: agent status, trading mode, kill-switch state. The scope note 'No account data' cleanly separates it from the account-scoped tools, though it does not name any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free:' signals it is costless to call, which is a soft usage cue, and 'No account data' implies it works without account context. There is no explicit when-to-use/when-not guidance, but the sibling set (market/odds tools) is orthogonal enough that selection ambiguity is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free: search open prediction markets by text. Returns market ids, outcomes and token ids.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden: it does disclose that access is free and that results contain market ids, outcomes and token ids, which is useful. It says nothing about result limits, pagination, auth, or behavior on no matches, so significant behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the scope and the return contract front-loaded. Nothing could be cut 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 compensates by enumerating the returned fields (ids, outcomes, token ids), and the 'open' qualifier scopes results. Missing pieces like result caps and pagination keep it from being fully complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the single parameter 'q' has no description, so the description must compensate. 'by text' is the only hint that q is a free-text query string, which adds marginal meaning but leaves matching semantics and formatting unspecified.
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: 'search open prediction markets by text', which unambiguously separates it from the odds/quote-oriented siblings. It doesn't explicitly name or contrast with any sibling, 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?
The word 'open' implies scope (only unresolved markets), and 'Free:' hints at cost, so usage is implied rather than stated. There is no explicit when-to-use, when-not-to-use, or named alternative among the sibling tools.
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.
estimate_fillget_odds_trendsget_odds_trends_summaryget_quoteget_statussearch_marketsLive prediction markets: Polymarket + Kalshi prices, odds, order books. Pay-per-call USDC, no key.
Crypto prices, gas, DeFi TVL, and live Polymarket odds. x402 pay-per-call, $0.001, no API key.
Market and on-chain crypto data for AI agents. Pay per call in USDC on Base (x402).
Pay-per-call crypto data on Base: market pulse, prices, chain snapshot, USDC stats. x402 USDC.
Add one secure layer between your agents and this server.