Skip to main content
Glama
Sign In

Vike Data API

by io.vike
OverviewDiscussionsAdmin

Predict.fun Markets

predictfun_markets
Read-onlyIdempotent

Predict.fun markets with each one's 24-hour USD volume, matches and wallets (the 24 whole fill hours ending with the newest hour built, up to ~1.5 h behind the live tape), largest volume first (or newest first). Filter by status (open, closed, resolved) and q (a substring of the title or question). Returns {markets, next_cursor, as_of_ts}; each market has market_id (what the other predictfun tools take), condition_id, title, question, status, trading_status, category_slug, created_at (epoch ms).

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": "predictfun_markets"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoCase-insensitive substring of the title or question.
sortNo`volume_24h` (default) or `newest`. A cursor works only with its own sort.
limitNoRows (default 20, max 100).
cursorNoA previous page's `next_cursor`, unchanged, to read the next page.
statusNoOnly markets in this state. Default: all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description's real addition is the freshness caveat — data ends at the newest built fill hour, up to ~1.5h behind the live tape — which is genuinely useful and not in annotations. No mention of rate limits, auth, or empty-result behavior, so it remains a moderate rather than rich disclosure.

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?

One front-loaded paragraph that leads with what is returned, then ordering, then filters, then the response shape. It is dense but nearly every clause carries information; the parenthetical describing the fill-hour window is slightly tangled and could be split for readability.

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 carries the return contract itself — `{markets, next_cursor, as_of_ts}` plus the per-market field list — and pagination is covered by naming `next_cursor`. For a 5-parameter, 0-required list tool that is essentially complete; only the null/terminal condition of `next_cursor` is left implicit.

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% and every parameter is documented there, including the enum values for `status` and `sort` and the cursor-must-match-sort rule. The description restates the status values, the substring semantics of `q`, and the sort ordering without adding format or edge-case detail beyond the schema; the one extra is the human-readable gloss on the volume window. Baseline 3 applies.

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 Predict.fun markets) plus exactly what each row carries — 24h USD volume, matches, wallets — and the ordering. The venue name and the `market_id` cross-reference distinguish it from the Polymarket sibling and from the per-market detail/book/trades tools.

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?

Explicit filters (`status`, `q`) and default sort are spelled out, and the note that `market_id` is 'what the other predictfun tools take' routes the agent onward to detail/flow tools. It stops short of saying when to prefer `predictfun_market_detail` or `polymarket_markets` instead, so no true when-not-to-use guidance.

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

All Vike Data API 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