BotSpot: AI Trading, Backtests and Bots

Discover broker markets and option contracts

broker_markets

Read-only

Read native instruments through a saved broker connection. Use search for prediction-market contracts/details/rules and options for a bounded option chain. Preserve native IDs and the saved account mode for subsequent quotes and trades.

Set "action" to choose the operation. Only send the fields listed for that action.

action="search": Find broker markets

No other fields required. Read-only native market/contract discovery through the signed-in user's saved broker connection. Use this before web search for contracts available on a connected prediction exchange such as Kalshi or Polymarket. Pass query to search, marketId to read one contract and its settlement rules, or eventId to list the child contracts of a native event; omit these selectors to browse. An event groups contracts and is not itself tradable: choose an exact returned child market identifier and outcome before quotes or approval. Results are bounded, not a complete venue inventory. Keep exact native identifiers and outcome mappings for get_broker_quotes and place_trade. The saved connection selects demo or live; demo availability/prices are not live forecasts. Never invent tickers or pass raw credentials.

action="options": Get broker option chain

Required fields: underlyingSymbol. Read-only: fetches option chain data from the signed-in user's saved broker connection. Always narrow large requests with expiration or expirationStart/expirationEnd, strikeMin/strikeMax, right, detailLevel, limit, or page. If the response is too large, retry using the provided retryWith suggestions. Never pass raw credentials.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "broker_markets"
  }
}

Input Schema

Name	Required	Description
`page`	No	Used with action="options".
`limit`	No	Used with action="search", action="options".
`query`	No	Used with action="search".
`right`	No	Used with action="options".
`action`	Yes	Which operation to run: "search", "options". See the tool description for each one.
`eventId`	No	Used with action="search".
`marketId`	No	Used with action="search".
`strikeMax`	No	Used with action="options".
`strikeMin`	No	Used with action="options".
`expiration`	No	Used with action="options".
`detailLevel`	No	Used with action="options".
`expirationEnd`	No	Used with action="options".
`includeGreeks`	No	Used with action="options".
`expirationStart`	No	Used with action="options".
`underlyingSymbol`	No	Used with action="options". Required for action="options".
`brokerCredentialId`	No	Used with action="search", action="options".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / eventId

Added value: +{
+  "description": "Used with action=\"search\".",
+  "maxLength": 512,
+  "minLength": 1,
+  "type": "string"
+}

AddedNov 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already signal readOnlyHint=true, but the description adds meaningful behavior: results are 'bounded, not a complete venue inventory', the saved connection selects demo or live and 'demo availability/prices are not live forecasts', events are not themselves tradable, and a retryWith hint is provided for oversized responses. Credential and identifier-safety warnings ('Never invent tickers or pass raw credentials') are also unique to the prose.

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?

Purpose is front-loaded in the first sentence and each action gets its own section with 'Only send the fields listed for that action', which is good structure. Some redundancy creeps in ('Read-only' stated twice, 'Never pass raw credentials' repeated in both sections), costing a little tightness.

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

Completeness4/5

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

For a 16-parameter, action-switched read tool with no output schema, the description covers selectors, required fields, narrowing guidance, size/retry behavior, and the identifier hand-off to downstream tools. It stops short of describing the shape of returned market/contract data (beyond 'outcome mappings'), which is the main residual gap.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: query searches, marketId reads one contract plus its settlement rules, eventId lists child contracts of an event, and omitting selectors browses. For options it stresses underlyingSymbol as required and lists the narrowing fields (expiration range, strike bounds, right, detailLevel, limit, page).

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 opens with a specific verb+resource ('Read native instruments through a saved broker connection') and then splits the two operations precisely: 'search' finds prediction-market contracts/details/rules, 'options' fetches a bounded option chain. It distinguishes itself from siblings get_broker_quotes and place_trade by naming them as the next step rather than duplicating them.

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?

Explicit routing: 'Use search for prediction-market contracts/details/rules and options for a bounded option chain', plus 'Use this before web search for contracts available on a connected prediction exchange such as Kalshi or Polymarket'. It also tells the agent to choose an exact child market before quotes/approval and to always narrow large option requests, so when-to-use and when-not are both covered.

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

All BotSpot: AI Trading, Backtests and Bots tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.