Skip to main content
Glama
Sign In

Syndicate

by trade.syndicate
OverviewDiscussionsAdmin

Get prediction event

get_prediction_event
Read-onlyIdempotent

One Polymarket event (all its outcomes) by event slug, event id, market slug or condition_id: each outcome's price, bid/ask and price history, plus live game state for sports. Prices are YES probabilities 0..1. interval is the history's lookback window (1h, 6h, 1d, 1w, 1m, max), not a bar size; keep it short (default 1d) on many-outcome events.

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": {
      "key": "<key>"
    },
    "name": "get_prediction_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyYesEvent slug, Gamma event id, market slug or condition id.
intervalNoPrice-history window (default 1d).
include_no_historyNoAdd binary outcomes' NO-side series (default false). It is always `1 - p` of `history`, so it only doubles the payload.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations' safe, read-only profile, the description discloses live sports state, YES-probability price units, the meaning of the history window, and a payload-size concern for large events. It does not cover history sampling, general data freshness, or not-found behavior, so it is informative without being exhaustive.

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

Conciseness5/5

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

Three dense sentences front-load the resource, lookup options, and returned data, then address units and the most error-prone parameter. There is no filler, and the performance warning earns its place.

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 three-parameter read-only lookup, the definition covers accepted identifiers, result scope, output contents, price units, history-window behavior, and payload considerations. Although no output schema documents the exact field layout, the description is sufficient for reliable tool selection and invocation.

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 description coverage is 100%, establishing a baseline of 3. The description adds meaningful semantics by clarifying that `interval` is a lookback window rather than a bar size and recommending shorter windows for many-outcome events; the identifier formats and enum values otherwise largely repeat the schema.

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 opening scope, "One Polymarket event (all its outcomes)," and the four accepted lookup keys precisely define a single-event retrieval operation rather than discovery or multi-market listing. It also names the principal returned data, helping distinguish it from the candle- and discovery-oriented siblings.

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?

An agent can infer when to use it: when it has an event slug, event id, market slug, or condition_id and wants that event's outcomes and history. The advice to keep `interval` short on many-outcome events adds practical invocation guidance, but there is no explicit when-not-to-use guidance or named alternative for discovery.

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

All Syndicate toolsInspect
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