Your agent needs the crowd's number — live odds on elections, policy, macro prints and sport, from the venues where people put money behind the opinion.
What you can ask for • "What are the current odds on this event?" • "List the open markets on this topic across both venues." • "Show recent trades and how the price moved." • "What is the implied probability now versus a week ago?"
How to use it Point any MCP client at https://mcp.aisa.one/prediction-market-data/mcp and sign in with OAuth — there is no key to create or paste. 5 tools: Kalshi markets and trades, Polymarket markets, events and activity.
Why this rather than the source Both venues in one shape, so the same question can be priced twice.
It is also a door to the rest The same login reaches 26 sources and 580+ operations. Read the odds here, then ask the same agent for the market data or the news behind them — without adding a second server.
What it costs Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident.
Where else it reaches https://mcp.aisa.one/finance/mcp for equities, crypto and prediction markets in one place.
Scored across 10 tools
The prediction-market tools are mostly distinct: markets vs. trades vs. events vs. wallet activity are clearly separated, and cross-references help. The only real overlap is get_kalshi_markets and get_polymarket_markets, which cover the same conceptual need on different venues, though the descriptions make the distinction explicit.
Most tools follow a consistent snake_case verb_noun pattern such as get_kalshi_markets, get_polymarket_events, and get_details. A few bare verbs like use and search, plus batch_use as a modifier, are minor deviations rather than a chaotic mix.
Ten tools is a well-scoped size for a server that combines prediction-market data access with AIsa meta-operations. Each tool has a clear role, and the count stays comfortably within the ideal range.
The server covers the core prediction-market data needs: current prices, trade history, event grouping, and wallet activity across two major venues. Minor gaps exist, such as the absence of a market-wide Polymarket trade tape or Kalshi event-level browsing, but agents can work around these with existing tools.
Execute up to 20 operations concurrently (tool-router's batch_use). Each item answers independently; one failure never cancels the others. Billed per call to your AIsa key.
| Name | Required | Description | Default |
|---|---|---|---|
| calls | Yes | Up to 20 items of {call_id, operation_id, arguments}; steps at the same execution_level of a plan go in one batch | |
| search_id | No | search_id from the search that found these operations | |
| max_price_usd | No | Per-call price cap applied to every item |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so safety is covered. The description adds valuable behavior: independence of items (one failure doesn't cancel others) and per-call billing. These are not derivable from annotations and help the agent set expectations.
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 short sentences with zero filler. The action and limit are front-loaded. The phrase 'tool-router's batch_use' is redundant since it restates the tool name, but it's a minor flaw. Overall it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering destructive behavior and an output schema presumably describing results, the description covers the key operational aspects: concurrency limit, independence, and billing. It doesn't mention error reporting formats, but those likely live in the output schema. It is sufficiently complete for a batch 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%, so the schema fully documents each parameter. The description adds no parameter-specific details. The calls parameter's description already explains the structure and batching context, so the baseline of 3 applies; the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (execute) and resource (operations) with a concrete limit (up to 20) and concurrency. It doesn't explicitly name the sibling 'use' for single operations, but the distinction is clear enough from the concurrency and limit. The redundancy of 'tool-router's batch_use' is minor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the sibling 'use' tool. The schema note about 'steps at the same execution_level of a plan go in one batch' is helpful, but it lives in the schema, not the description. The description only implies batching via concurrency but doesn't state when to choose it over the single-operation alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full contract of one or more operations: arguments_schema, response_schema, read_only, side_effects, availability, price, suggested_max_price_usd and known_pitfalls. Free — a quote authenticates like a call but stops before any spend.
price.model distinguishes the sources: quoted is what this
account would be charged now, list is the published price,
dynamic means the price varies with the request and only a quote
states it, composed means the operation runs several upstream
calls. suggested_max_price_usd is that estimate with headroom,
in the shape use and batch_use take as max_price_usd.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | The arguments the operation would be called with, for a price that reflects them. Keyed by operation_id for a batch, or passed flat for a single operation_id. Routes whose required parameters are validated before pricing have no price without them. | |
| with_quote | No | Whether each operation is priced for this account before the answer. One round trip per operation; spends nothing. | |
| operation_id | No | One operation_id from search | |
| operation_ids | No | Up to 20 operation_ids, for a batch |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: it is free, stops before any spend, and explains how price.model varies (quoted, list, dynamic, composed). It also clarifies that suggested_max_price_usd has headroom. This goes beyond the annotation flags and gives the agent a clear model of what happens.
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 moderately long but well structured: it opens with the core purpose, then explains the price model in a dedicated paragraph. No redundancy or filler. It front-loads the most critical information (contract fields) and then gives necessary detail about price semantics. Slightly dense but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need no description. The description covers the key behavioral aspects (no spend, pricing models, max_price headroom) and clarifies edge cases like routes without a price. For a read-only informational tool, this is complete enough for an agent to use 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 parameters are already documented. The description adds some nuance, such as how arguments affect pricing and that required parameters may be needed before a price can be quoted. It also clarifies with_quote's purpose (one round trip, spends nothing). These are useful but not essential given the schema's completeness.
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 purpose: returning the full contract of one or more operations, including schemas, read_only, side_effects, price, and known_pitfalls. It clearly distinguishes this from executing operations (use, batch_use) and from discovery (search, list_categories). The verb 'get' and the noun 'details' align with the title, and the first sentence is explicit.
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 tool is used to assess an operation before spending (e.g., 'A quote authenticates like a call but stops before any spend'), and the schema says 'One operation_id from search', hinting at a flow. However, it never explicitly states when to choose this over siblings like use or search, nor does it give exclusions. The guidance is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List markets on Kalshi, the CFTC-regulated US prediction exchange, with live bid/ask quotes in dollars. Use this when you need odds from a regulated venue, or to cross-check a Polymarket price against a second market; fetch specific markets with tickers (comma-separated), scope to a group with event_ticker / series_ticker, or narrow with status, search, and the created / close / settled timestamp ranges.
Returns markets[] with title, status, yes_bid_dollars / yes_ask_dollars, last_price_dollars, volume_fp, open_interest_fp, and rules_primary (the settlement criteria), plus a cursor to page with.
For executed fills rather than quotes, use get_kalshi_trades. For the crypto-native venue carrying similar questions, use get_polymarket_markets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. Defaults to 100. Maximum value is 1000. | |
| cursor | No | Pagination cursor from the previous response. | |
| search | No | Search markets by keywords in title and description. Must be URL encoded (e.g., 'bitcoin%20price' for 'bitcoin price'). | |
| status | No | Filter markets by status. | |
| tickers | No | Comma-separated Kalshi market tickers to retrieve. | |
| mve_filter | No | Filter by multivariate events. | |
| event_ticker | No | Filter by a single Kalshi event ticker. | |
| max_close_ts | No | Filter markets closing before this Unix timestamp. | |
| min_close_ts | No | Filter markets closing after this Unix timestamp. | |
| series_ticker | No | Filter by series ticker. | |
| max_created_ts | No | Filter markets created before this Unix timestamp. | |
| max_settled_ts | No | Filter markets settled before this Unix timestamp. | |
| min_created_ts | No | Filter markets created after this Unix timestamp. | |
| min_settled_ts | No | Filter markets settled after this Unix timestamp. | |
| min_updated_ts | No | Filter markets updated after this Unix timestamp. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, open-world, non-destructive behavior, so the bar is lower. The description adds genuinely new context: the tool returns live quotes rather than executed fills, the settlement criteria are exposed via rules_primary, and pagination is cursor-based. This enriches the agent's model of what the invocation produces without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight paragraphs with clear structure: purpose/usage first, return shape second, alternatives third. Every sentence earns its place. The middle paragraph listing return fields is slightly redundant with the existing output schema, which costs a point, but the overall organization is strong and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-required-parameter list tool with a rich schema, annotations, and output schema, the description covers everything an agent needs: purpose, regulatory framing, when-to-use vs alternatives, filtering strategy, return fields, settlement criteria, and pagination. No critical gap remains; rate limits and error cases would be marginal additions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds organizational value by grouping the 15 parameters into use-case clusters (fetch specific markets via tickers, scope via event_ticker/series_ticker, narrow via status/search/timestamp ranges), which helps an agent pick the right filter for its goal. This exceeds the baseline but does not add per-parameter detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'List markets on Kalshi' — and adds distinguishing qualifiers ('CFTC-regulated US prediction exchange', 'live bid/ask quotes in dollars') that separate it from the other market venues in the sibling list. It also explicitly names what it is not ('For executed fills rather than quotes, use get_kalshi_trades'), so an agent can disambiguate without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use this when you need odds from a regulated venue, or to cross-check a Polymarket price against a second market') and names both alternatives with the exact conditions that select them (get_kalshi_trades for fills, get_polymarket_markets for the crypto-native venue). 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.
Get the executed-trade tape for Kalshi markets — actual fills, not quotes. Use this when you need realized prices and traded size over a window, for example to see how conviction moved while an event unfolded; narrow with ticker and the min_ts / max_ts Unix-second range, and set is_block_trade to isolate large negotiated trades.
Returns trades[] with trade_id, ticker, count_fp (contracts), yes_price_dollars / no_price_dollars, taker_side, and created_time, plus a cursor to page with.
For the current quotes, settlement rules, and market metadata rather than fills, use get_kalshi_markets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results per page. Defaults to 100. Maximum value is 1000. | |
| cursor | No | Pagination cursor from the previous response. | |
| max_ts | No | Filter trades before this Unix timestamp. | |
| min_ts | No | Filter trades after this Unix timestamp. | |
| ticker | No | Filter by Kalshi market ticker. | |
| is_block_trade | No | Filter trades by whether they are block trades. Omit to return all trades. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already marking this as read-only, idempotent, and non-destructive, the description adds useful behavioral context: it returns actual fills (not quotes), the list of fields, and the pagination cursor. It does not introduce unrelated claims and adds insight beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and purposeful, opening with the core purpose and then moving to usage guidance, return shape, and the sibling alternative. Minor redundancy with the output schema (detailed return fields) keeps it from a 5, but every sentence 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 6 parameters, full schema coverage, an output schema, and safe/read-only annotations, the description provides sufficient context for correct invocation. It covers the when-to-use, how-to-filter, and what-to-expect, while pointing to the relevant sibling tool. The only gap is lack of explicit mention of authentication/rate limits, but the annotations already signal a harmless read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds value by explaining how parameters combine (narrow with ticker and time range, set is_block_trade to isolate large negotiated trades), which goes beyond the schema's simple per-field filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') on a specific resource ('executed-trade tape for Kalshi markets') and explicitly differentiates itself from quotes and from get_kalshi_markets, making it easy for an agent to distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use this tool ('when you need realized prices and traded size over a window'), gives concrete filtering guidance with ticker, min_ts/max_ts, and is_block_trade, and explicitly tells the agent to use get_kalshi_markets when quotes/settlement/metadata are needed instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one wallet's on-chain Polymarket activity — a per-address lookup, not a market-wide trade feed. The user parameter is required. Use it to reconstruct what a specific trader did — position splits, merges and redemptions, with size, price, and the transaction that settled them; narrow further with market_slug, condition_id, and the start_time / end_time Unix-second range.
Returns activities[] with side (MERGE / SPLIT / REDEEM), market_slug, condition_id, shares, price, timestamp, and tx_hash, plus a pagination object whose key you pass back as pagination_key.
For market-wide prices rather than one wallet's history, use get_polymarket_markets.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Wallet address or user identifier. Required by the runtime route. | |
| limit | No | Number of activities to return (1-1000) | |
| end_time | No | Filter activity until this Unix timestamp in seconds (inclusive) | |
| start_time | No | Filter activity from this Unix timestamp in seconds (inclusive) | |
| market_slug | No | Filter activity by market slug | |
| condition_id | No | Filter activity by condition ID | |
| pagination_key | No | Base64-encoded cursor for efficient pagination. Returned in the previous response's pagination object. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds meaningful behavioral detail beyond annotations: it explains that the tool returns specific activity types (MERGE/SPLIT/REDEEM), includes a pagination object whose key must be passed back, and requires the user parameter. This gives the agent a clear model of how the tool behaves without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into three short paragraphs, each with a distinct job: scope definition, behavioral/return detail, and alternative routing. Every sentence carries information; there is no redundant or promotional text. The structure is front-loaded with the core purpose before discussing filters and return fields.
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 lookup with 7 parameters and an existing output schema, the description covers all essential decision points: the required parameter, available filters, response shape, pagination mechanics, and when to choose a different tool. An agent has sufficient information to invoke it correctly and interpret the result, with no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by stating that `user` is required, grouping `market_slug`, `condition_id`, and the time range as narrowing filters, and explaining that `pagination_key` comes from the previous response's pagination object. This enrichment goes beyond the schema's individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get one wallet's on-chain Polymarket activity' and immediately distinguishes it from a market-wide trade feed. It clearly names the scope (per-address lookup) and the entity involved (a specific trader), making it easy to differentiate from the sibling get_polymarket_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool ('Use it to reconstruct what a specific trader did') and contrasts it with an alternative: 'For market-wide prices rather than one wallet's history, use get_polymarket_markets.' This provides direct routing guidance with no reliance on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Polymarket events — the topic-level grouping that bundles related markets, such as an election or a season-long series. Use this to browse by subject rather than by individual question, or to find every market attached to one storyline; filter with tag_slug, active, featured, archived, closed, and the liquidity / volume ranges.
Returns a top-level array of event objects with title, ticker, slug, volume, volume24hr, liquidity, startDate / endDate, and a nested markets array holding the tradable questions.
When you already know which question you want and need its price, use get_polymarket_markets instead.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by one or more event IDs. | |
| slug | No | Filter by one or more event slugs. | |
| limit | No | Maximum number of events to return. | |
| order | No | Comma-separated list of fields to order by. | |
| active | No | Filter by active events. | |
| closed | No | Filter by whether the event is closed. | |
| offset | No | Number of events to skip for offset-based pagination. | |
| tag_id | No | Filter by tag ID. | |
| archived | No | Filter by archived events. | |
| featured | No | Filter by featured events. | |
| tag_slug | No | Filter by tag slug. | |
| ascending | No | Sort ascending when true. | |
| volume_max | No | Maximum volume. | |
| volume_min | No | Minimum volume. | |
| end_date_max | No | Filter events ending before this ISO timestamp. | |
| end_date_min | No | Filter events ending after this ISO timestamp. | |
| liquidity_max | No | Maximum liquidity. | |
| liquidity_min | No | Minimum liquidity. | |
| start_date_max | No | Filter events starting before this ISO timestamp. | |
| start_date_min | No | Filter events starting after this ISO timestamp. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context beyond that by specifying the return shape: a top-level array of event objects with key fields and a nested markets array. This helps the agent understand what the call produces without relying only on the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose first, then usage guidance, then return shape, then sibling routing. Every sentence earns its place, and the alternative tool guidance is placed at the end without clutter.
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 the rich input schema, annotations, and output schema, the description covers the essential conceptual context: what an event is, how it differs from a market, how to browse/filter, what the response contains, and when to use a sibling tool. Nothing critical is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions some filters (tag_slug, active, featured, archived, closed, liquidity/volume ranges) and the return fields, but it does not add substantive meaning beyond what the input schema already documents for each parameter. It is useful but not additive enough to raise the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List Polymarket events'. It then defines what an event is (topic-level grouping bundling related markets) and gives concrete examples (election, season-long series), making the tool's purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'Use this to browse by subject rather than by individual question, or to find every market attached to one storyline.' It also names the alternative: 'When you already know which question you want and need its price, use get_polymarket_markets instead.' This is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List individual Polymarket prediction markets — one binary question each — with live pricing. Use this when you need the market-implied probability of a specific outcome, or to screen markets by size and timing; filter with slug, condition_ids, clob_token_ids, tag_id, closed, and the volume_num_* / start_date_* / end_date_* ranges.
Returns a top-level array of market objects. The probability signal is outcomes paired with outcomePrices, quoted against bestBid / bestAsk; conditionId and clobTokenIds are the on-chain identifiers you need to join to other Polymarket data.
For the topic that groups several related questions together, use get_polymarket_events. For the same kind of question on the US-regulated Kalshi exchange, use get_kalshi_markets.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by one or more Polymarket market IDs. | |
| slug | No | Filter by one or more market slugs. | |
| limit | No | Maximum number of markets to return. | |
| order | No | Comma-separated list of fields to order by. | |
| closed | No | Filter by whether the market is closed. | |
| offset | No | Number of markets to skip for offset-based pagination. | |
| tag_id | No | Filter by tag ID. | |
| ascending | No | Sort ascending when true. | |
| include_tag | No | Include tag metadata when true. | |
| end_date_max | No | Filter markets ending before this ISO timestamp. | |
| end_date_min | No | Filter markets ending after this ISO timestamp. | |
| condition_ids | No | Filter by one or more market condition IDs. | |
| clob_token_ids | No | Filter by one or more CLOB token IDs. | |
| start_date_max | No | Filter markets starting before this ISO timestamp. | |
| start_date_min | No | Filter markets starting after this ISO timestamp. | |
| volume_num_max | No | Maximum total volume. | |
| volume_num_min | No | Minimum total volume. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral detail: it states the output is a top-level array, clarifies that the probability signal is in `outcomes` paired with `outcomePrices` and quoted against `bestBid`/`bestAsk`, and identifies `conditionId`/`clobTokenIds` for joining to other data. This 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?
The description is exactly three well-focused paragraphs: purpose with inline filter enumeration, return-shape explanation, and sibling routing. Every sentence adds information. No filler or repetition of the title, and the most important usage guidance (when to use) is front-loaded in the first sentence.
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 17 parameters, an output schema, and strong annotations, the description fully covers the tool's purpose, return-shape semantics, parameter categories, and sibling alternatives. An agent can decide to call this tool, know what it returns, and join the results to other Polymarket data without needing to open another schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already provides per-parameter descriptions and examples. The description adds semantic grouping beyond that: it names the exact filter parameters for market size and timing ('slug', 'condition_ids', 'clob_token_ids', 'tag_id', 'closed', and the volume/date ranges) and explains that some in-schema fields are on-chain identifiers for joining. It does not re-describe every parameter but meaningfully aggregates them for output.
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: 'List individual Polymarket prediction markets — one binary question each — with live pricing.' It immediately distinguishes itself by calling out the use case—market-implied probability of a specific outcome or screening by size and timing—and explicitly differentiates from siblings get_polymarket_events and get_kalshi_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'Use this when you need the market-implied probability of a specific outcome, or to screen markets by size and timing.' It also gives direct when-not guidance by routing users to get_polymarket_events for grouped topics and get_kalshi_markets for the US-regulated exchange. It names alternatives with clear criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The AIsa catalogue at a glance: categories, the servers in each, tool counts, and the dedicated endpoint to connect if you only need one category. Free; no key needed. (AIsa-only: tool-router has no equivalent.)
Use mcp.aisa.one/mcp?modules=<category> (or mcp.aisa.one/<category>/mcp)
to have that category's tools listed directly instead of via search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: the tool is free, requires no key, and can direct users to a category-specific endpoint that lists tools directly rather than through search.
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 moderately detailed but every sentence adds useful information: output scope, cost/auth, sibling differentiation, and endpoint usage. It is slightly longer than strictly necessary but remains well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema and safety annotations, the description is complete. It covers what the tool returns, the free/no-key access model, and provides the category endpoint for specialized use, leaving no essential gap for an agent 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?
The tool has zero parameters, so the baseline is 4. The description includes a <category> placeholder only in the endpoint examples, not as a tool parameter, which is appropriate supplementary guidance rather than a parameter-semantics 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 clearly states what the tool does: it presents the AIsa catalogue at a glance, including categories, servers, tool counts, and a dedicated category endpoint. It also distinguishes itself from search by explaining that the endpoint lists tools directly instead of via search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use list_categories for a catalogue overview, and use the provided endpoint when you only need one category. It explicitly contrasts with search ('instead of via search') and notes tool-router has no equivalent, although it does not exhaustively cover all sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find AIsa data operations across SEO & AI visibility, finance, social, web search & research, sales and agent mail — 950+ APIs — by describing the task. Free; no key needed.
Returns tool-router's SearchResponse: retrieval_mode (plan |
endpoint | clarification), an optional plan, and candidates with
operation_id, provider, method, path, summary, required_inputs,
price, match_reasons and details_ref — plus input_schema, so a
candidate can be passed to use without calling get_details, and
modules, the entry points that pin it.
Search spans the full AIsa catalogue, not only the category pinned
on this endpoint, so an operation is discoverable here even when it
is not in the current tools/list; a candidate whose modules does
not include the current one still runs. When more than one provider
offers the same metric, the candidates make that visible.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum candidates, 1-10 | |
| query | Yes | What you need, in plain language, e.g. 'backlinks of a domain', 'recent tweets by a user', 'insider trades for AAPL'. English works best. | |
| category | No | Restrict to one category (seo, finance, social, search, sales, mail). Omit to search everything. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses meaningful behavior beyond annotations: search spans the entire AIsa catalogue, candidates may belong to modules other than the current one, multiple providers for the same metric are surfaced, and no API key is required. This gives the agent a clear picture of scope and output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and is dense with useful information: scope, no-auth requirement, response shape, and relationship to the catalogue. Each sentence adds operational value, and the structure makes the tool's behavior predictable.
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 complex discovery tool with output schema, the description is unusually complete: it explains the response modalities, candidate fields, direct pass-through to `use`, full-catalogue search behavior, and cross-provider visibility. An agent has enough context to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining that the category parameter is not a hard boundary—search spans the full catalogue—and that queries are plain-language task descriptions, which clarifies how to use the tool effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds AIsa data operations across many categories via a plain-language query. It distinguishes itself from siblings like get_details and use by emphasizing that search covers the full catalogue, not just the pinned category.
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 conveys when to use search: when you need to discover operations across the full catalogue, even those not in the current tools/list. It also implicitly contrasts with get_details by noting that returned candidates already include input_schema, so they can be passed directly to `use` without an extra call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one AIsa operation. Billed per call to your AIsa key.
Answers in tool-router's BatchCallResult shape: successful, data or error {type, status, message, retryable}. Pinned tools in tools/list can also be called directly; this is the way to call anything found through search.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | Arguments matching input_schema / arguments_schema | |
| search_id | No | search_id from the search that found this operation | |
| operation_id | Yes | operation_id as returned by search | |
| max_price_usd | No | Refuse the call before any spend if it would cost more than this many USD |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly=false, openWorldHint=true, and destructiveHint=true. The description adds valuable behavior beyond that: billing per call, the BatchCallResult response shape, and the error structure with retryable status. It does not spell out side effects, but the destructive flag is already carried by annotations, so the additional context is sufficient.
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 short sentences, each earning its place: purpose, cost, response shape, and routing guidance. Key behavioral facts are front-loaded, and nothing is redundant with the schema 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?
Given that an output schema exists and all parameters have descriptions, the tool description is complete enough for correct invocation. It covers cost, return/error contracts, and how routing to this tool differs from calling pinned tools directly, leaving no practical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter is already clearly documented: operation_id as returned by search, search_id provenance, arguments matching input_schema, and max_price_usd as a spend guard. The description does not need to add parameter detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Execute one AIsa operation,' a specific verb+resource statement. The word 'one' distinguishes it from the sibling batch_use, and the closing note distinguishes it from calling pinned tools directly. An agent can tell what this tool is for immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'this is the way to call anything found through search.' It also gives the alternative: 'Pinned tools in tools/list can also be called directly.' This is clear when-versus-alternative guidance with no ambiguity.
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.
batch_useget_detailsget_kalshi_marketsget_kalshi_tradesget_polymarket_activityget_polymarket_eventsget_polymarket_marketslist_categoriessearchuseYour agent needs markets — prices and fundamentals for listed companies, the filings behind them, crypto, and what the prediction markets put the odds at. **What you can ask for** • "Pull this company's income statement, cash flow and balance sheet for the last 8 quarters." • "What did insiders buy or sell, and when?" • "Snapshot prices for these 50 tickers, then the OHLC history for the three that moved." • "What are the current odds on this event across Kalshi and Polymarket?" • "Screen for companies matching these financial criteria." **How to use it** Point any MCP client at https://mcp.aisa.one/finance/mcp and sign in with OAuth — there is no key to create or paste. 49 tools: prices and snapshots, income statements, balance sheets and cash flows, metrics and ratios, earnings and analyst estimates, filings and line-item search, insider trades, macro interest rates, news, a screener; CoinGecko spot prices, market tables, OHLC, per-venue tickers and trending; Kalshi and Polymarket markets and trades; plus EDINET filings for Japan. **Why this rather than the source** Equities, crypto and event markets behind one account, so a cross-asset question is one conversation. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the number here, then ask the same agent what X is saying about the ticker today — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/marketpulse/mcp · /crypto-market-data/mcp · /prediction-market-data/mcp · /stock-pulse/mcp for one slice each.
Your agent needs company financials it can compute on — statements, ratios, earnings, estimates, filings and insider activity as structured data, not a PDF. **What you can ask for** • "Give me 8 quarters of income statement, balance sheet and cash flow for this ticker." • "What do analysts estimate for next quarter, and how did the last four surprise?" • "Find this exact line item across every filing." • "Who bought or sold as an insider in the last 90 days?" • "Screen for profitable companies under this valuation with growing revenue." **How to use it** Point any MCP client at https://mcp.aisa.one/marketpulse/mcp and sign in with OAuth — there is no key to create or paste. 21 tools: prices and snapshots, income statements, balance sheets, cash-flow statements, financial metrics and snapshots, earnings, analyst estimates, company facts, filings and filing items, line-item search, a screener, insider trades, macro interest rates, news, plus EDINET documents and filing digests for Japanese issuers. **Why this rather than the source** Statements as fields you can compute on, and a screener in the same place. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the fundamentals here, then ask the same agent what social is saying about the ticker — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/finance/mcp for equities, crypto and prediction markets in one place.
Your agent needs the two halves of a move at once — what people are posting about a ticker right now, and what the price and the news actually did. **What you can ask for** • "What is X saying about $NVDA today, and what did the stock do?" • "Show the chatter and the price move for these five tickers side by side." • "Which tickers are being talked about most right now?" • "Pull the news and the snapshot behind this spike." **How to use it** Point any MCP client at https://mcp.aisa.one/stock-pulse/mcp and sign in with OAuth — there is no key to create or paste. 4 tools: a combined stock-pulse call that joins X/Twitter chatter to the tickers mentioned, plus advanced tweet search, price snapshots and financial news. **Why this rather than the source** One call instead of four, with the join already done. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Spot the move here, then ask the same agent for the filings or the fundamentals behind it — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/finance/mcp for equities, crypto and prediction markets in one place.
Your agent needs crypto prices it can rely on — spot, ranked market tables, history, OHLC, per-venue tickers, and what is trending right now. **What you can ask for** • "What is the price of these 20 tokens in USD and EUR right now?" • "Give me the top 100 by market cap with 24h and 7d change." • "Chart this coin's price over the last year, hourly." • "Where does this token trade, and at what spread per venue?" • "What is trending on CoinGecko today?" **How to use it** Point any MCP client at https://mcp.aisa.one/crypto-market-data/mcp and sign in with OAuth — there is no key to create or paste. 21 CoinGecko tools: simple price and token price by contract, supported currencies, coin list and detail, ranked markets, history, market charts and ranges, OHLC, per-coin tickers, categories, exchanges and their tickers, token data and charts, and trending. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Price the token here, then ask the same agent what X is posting about it — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/finance/mcp for equities, crypto and prediction markets in one place.
Add one secure layer between your agents and this server.
