Skip to main content
Glama
Sign In

Vectorial Data Terminal: Hyperliquid, Polymarket & yield for AI agents

by com.vectorialdata
OverviewDiscussionsAdmin

list_prediction_markets

Read-only

Prediction markets you can trade now (Polymarket): events with their markets and, per outcome, the CLOB token_id you trade and its price (a probability 0–1 = USD per share; a winning share pays $1). Default: by 24h volume. Optional: query (search), event_slug (one event), tag (a Gamma tag slug, e.g. sports, politics, crypto), limit (≤50), offset.

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_prediction_markets"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagNoA Polymarket tag slug, e.g. sports, politics, crypto
limitNoEvents per page, 1–50
queryNoFree-text search, e.g. 'fed rates' or 'lakers'
offsetNoHow many events to skip (pagination)
event_slugNoReturn one event by its slug (from an earlier listing)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / event_slug / description
      Added value: +"Return one event by its slug (from an earlier listing)"
    • addedInput schema / properties / limit / description
      Added value: +"Events per page, 1–50"
    • addedInput schema / properties / offset / description
      Added value: +"How many events to skip (pagination)"
    • addedInput schema / properties / query / description
      Added value: +"Free-text search, e.g. 'fed rates' or 'lakers'"
    • addedInput schema / properties / tag / description
      Added value: +"A Polymarket tag slug, e.g. sports, politics, crypto"
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value by explaining that each outcome carries a CLOB token_id and a 0–1 probability price that pays $1 on a win. That is downstream-critical context an agent cannot get from annotations. It does not mention pagination limits or rate/liveness caveats beyond 'you can trade now'.

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?

The core purpose and price semantics are front-loaded in the first sentence, with parameter notes listed compactly afterward. The parenthetical parameter rundown is dense but each clause carries information; a slightly more explicit routing sentence would round it out.

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?

With no output schema, the description does the necessary work of describing the return structure (events, markets, per-outcome token_id and price) and the price interpretation. Missing only edge-case behavior such as what happens when event_slug matches nothing or how filters combine.

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 coverage is 100%, so tag slug examples, limit range and offset semantics are already documented in the schema. The description mostly repeats them; its only meaningful addition is framing event_slug as returning a single event. Baseline 3 applies.

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

Purpose4/5

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

The description names a specific verb+resource ('Prediction markets you can trade now (Polymarket)') and states the returned shape (events with markets, per-outcome token_id and price). It is clearly separable from generic listing tools like list_markets, though it never names a sibling explicitly.

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

Usage Guidelines3/5

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

It gives the default ordering ('by 24h volume') and characterizes each optional filter in parentheses, which implies how to use them. It stops short of saying when to prefer this over get_prediction_book or get_prediction_positions, or when-not to use it.

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

All Vectorial Data Terminal: Hyperliquid, Polymarket & yield for AI agents 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