Fivebar Trading

Prediction market odds (Polymarket)

prediction_markets

Read-only

Search Polymarket's open prediction markets by topic. Use short, neutral topic words, the way a market would be named: 'House 2026' or 'which party wins the House', not 'Republicans lose the House'; 'Fed rate cut', 'bitcoin November'. Results are the matching events ranked by total volume, busiest first (pass rank 'relevance' for Polymarket's own text order): the headline market on a topic is usually the busiest, so for 'the most traded market about X' the first result is the answer; if none of the results asks the question directly, search again with other words. For each event: its markets with the Yes odds in percent, the change over 24 hours and a week (in points), volume, liquidity, the date it closes (not the event's own date), status, and a link. Markets with a wide spread or little liquidity are marked thin. Read-only market prices from Polymarket's public API, not forecasts or advice. Use for 'what are the odds of...', 'will X happen?', 'what does Polymarket say about...'. Then prediction_market for one market's history: pass the market's ref.

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": {
      "query": "<query>"
    },
    "name": "prediction_markets"
  }
}

Input Schema

Name	Required	Description
`rank`	No	Order of the results: by volume (default) or Polymarket's text relevance
`limit`	No	Events to return, default 5, max 10
`query`	Yes	Topic in a few words
`include_closed`	No	Also return resolved markets (for 'how did X resolve?'). Default false

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / rank

Added value: +{
+  "description": "Order of the results: by volume (default) or Polymarket's text relevance",
+  "enum": [
+    "volume",
+    "relevance"
+  ],
+  "type": "string"
+}

AddedNov 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover readOnly and openWorld, but the description adds substantial context: results are events ranked by volume (busiest first) unless rank='relevance', closed markets are excluded by default, thin markets with wide spread are flagged, and data is public API pricing rather than advice. The main omission is anything about failure modes (no matches, API limits), but the behavioral picture is otherwise well drawn.

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?

Dense but front-loaded: purpose, then query style, then ordering behavior, then return shape, then triggers and the sibling hand-off. Slightly long with a few parenthetical asides, and the read-only disclaimer is arguably padding, but nearly every clause carries usable information.

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?

There is no output schema, and the description compensates by enumerating the returned per-market fields (Yes odds in percent, 24h/weekly point change, volume, liquidity, close date, status, link) and naming the ranking key. For a four-parameter read tool this leaves nothing an agent needs missing.

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, and the description earns above that by adding query phrasing guidance ('short, neutral topic words ... not "Republicans lose the House"') and by explaining rank semantics as Polymarket's own text order versus volume. limit and include_closed get only what the schema already says.

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?

Opens with a specific verb and resource — 'Search Polymarket's open prediction markets by topic' — and names the sibling prediction_market as the follow-up for a single market's history. An agent can tell it apart from the other market tools 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?

Gives explicit trigger phrases ('what are the odds of...', 'will X happen?'), conditional guidance on re-searching with different words when results don't ask the question, a rule for 'the most traded market about X', and a pointer to include_closed for 'how did X resolve?'. It also routes follow-up history requests to prediction_market via the market `ref`.

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

All Fivebar Trading 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.