Gaduin

List prediction markets

list_markets

Read-onlyIdempotent

List prediction markets on real-world transport outcomes (flight delays, train punctuality, ship arrivals, weekly ship counts through maritime chokepoints, airport flight counts), filtered by status (OPEN by default; CLOSED, SETTLED or CANCELLED for past ones), category and a free-text query matched against the route, flight number, airline, airport codes and vehicle. Returns each market's id, link, category, question, route, outcomes with current prices, volume, close time and, once settled, the outcome it settled on.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_markets"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max number of markets to return (1-100). Defaults to the server's page size.
`query`	No	Free text such as BA117, JFK, Paddington or Suez. Omit to list everything matching the other filters.
`status`	No	Filter by market status: OPEN (trading), CLOSED (awaiting settlement), SETTLED or CANCELLED. Defaults to OPEN.
`category`	No	Filter to one transport category. Omit to get all.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 12, 2026

changedInput schema / properties / limit / description

Previous value: -"Max number of markets to return. Defaults to server preference."New value: +"Max number of markets to return (1-100). Defaults to the server's page size."

addedInput schema / properties / query

Added value: +{
+  "description": "Free text such as BA117, JFK, Paddington or Suez. Omit to list everything matching the other filters.",
+  "maxLength": 64,
+  "type": "string"
+}

changedInput schema / properties / status / description

Previous value: -"Filter by market status. Defaults to OPEN."New value: +"Filter by market status: OPEN (trading), CLOSED (awaiting settlement), SETTLED or CANCELLED. Defaults to OPEN."

First observedNov 12, 2026

TDQS

A4.4/5.0

Behavior4/5

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 real behavioral value beyond them: the default status filter (a silent result-shaping behavior), the fields the free-text query is matched against, and the contents of each returned record including settlement outcome.

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?

Front-loads the resource and its domain, then folds filters and return shape into one dense sentence with no filler. The return-field enumeration is long but justified because no output schema exists; a slight cost is that the single run-on sentence makes the filters harder to scan.

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?

With four optional params, no required fields and no output schema, the description carries the return-value burden itself and does so fully: id, link, category, question, route, outcomes with prices, volume, close time and settled outcome. Defaults and matching fields are also covered, so an agent can call it correctly without further information.

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 a baseline of 3 applies, but the description earns extra credit by explaining that query matches route, flight number, airline, airport codes and vehicle — matching behavior the schema only illustrates with examples. It also restates the OPEN default, reinforcing the status enum's effect.

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?

States a specific verb and resource ('List prediction markets') and pins down the domain precisely: transport outcomes across flight delays, train punctuality, ship arrivals, chokepoint counts and airport counts. That scope makes it immediately distinguishable from siblings like list_chokepoints or list_disrupted_airports, which cover only one slice of the same domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives clear operational context: status defaults to OPEN and CLOSED/SETTLED/CANCELLED must be requested explicitly for past markets, and 'omit to list everything matching the other filters' clarifies query semantics. It does not, however, name an alternative such as get_market for fetching a single market by id, so the boundary with that sibling is left implicit.

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

All Gaduin 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.

Resources

Need Help?