Skip to main content
Glama
YichengYang-Ethan

oracle3

by YichengYang-Ethan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_markets

Read-only

Search open Kalshi or Polymarket markets to find market IDs and best bid/ask prices. Use results to fetch live quotes or order books without an API key.

Instructions

Search open Kalshi or Polymarket markets and return candidates with their best prices.

Start here to find market ids, then call get_quote or get_orderbook for live
prices, or get_market for resolution details. Reads the venues' public APIs,
so no account or API key is needed; Kalshi keyword search scans up to 1,000
open events. Returns {venue, query, count, markets}; each market has
market_id, title, best bid and ask in dollars, volume and closing date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum markets to return, 1-100 (clamped). Default 20.
queryNoCase-insensitive keywords matched against event titles, market titles and (on Kalshi) tickers. Empty lists open markets without a keyword filter.
venueYesVenue: 'kalshi' or 'polymarket'.
series_tickerNoKalshi only: list the open markets of this series (e.g. KXFEDDECISION) instead of searching by keyword; query is then ignored. Ignored on Polymarket.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.2.2
    • addedInput schema / properties / limit / description
      Added value: +"Maximum markets to return, 1-100 (clamped). Default 20."
    • addedInput schema / properties / query / description
      Added value: +"Case-insensitive keywords matched against event titles, market titles and (on Kalshi) tickers. Empty lists open markets without a keyword filter."
    • addedInput schema / properties / series_ticker / description
      Added value: +"Kalshi only: list the open markets of this series (e.g. KXFEDDECISION) instead of searching by keyword; query is then ignored. Ignored on Polymarket."
    • addedInput schema / properties / venue / description
      Added value: +"Venue: 'kalshi' or 'polymarket'."
  2. First observedv1.2.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds meaningful context beyond them: no account or API key is required because it reads public APIs, and Kalshi keyword search scans up to 1,000 open events. It omits rate limits and pagination behavior, so it is strong but not complete.

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

Conciseness4/5

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

Three tight sentences, front-loaded with purpose then routing then behavior. The final sentence enumerating return fields is partially redundant with the output schema, which slightly blunts conciseness, but nothing is padded.

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

Completeness5/5

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

For a read-only, public-API search with an output schema and readOnly/openWorld annotations already present, the description covers purpose, sibling routing, auth requirements, and result contents. Nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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 limit, query, venue and series_ticker including the Kalshi-only semantics. The description only echoes the Kalshi keyword-scan behavior, adding little parameter meaning beyond the structured fields; baseline 3 applies.

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

Purpose5/5

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

The description states a specific verb and resource ('Search open Kalshi or Polymarket markets') and names the return shape ('candidates with their best prices'), which cleanly separates it from quote/orderbook/market-detail siblings. An agent can identify the tool's role 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.

Usage Guidelines5/5

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

It explicitly positions itself as the entry point ('Start here to find market ids') and routes to alternatives by need: get_quote/get_orderbook for live prices, get_market for resolution details. The when-to-use and which-sibling-to-pick guidance is fully spelled out.

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

Deploy Server

Other Tools