Fillin

query_markets

Read-onlyIdempotent

Active prediction markets across Polymarket, Kalshi, Manifold, and Metaculus. Use when a user asks "is there a market on X", "what odds is the market giving Y", or before any agent action that should be informed by a market price.

Requires $0.01–$0.05 USDC (x402) or an Authorization Bearer trial/paid key.
On payment_required, call fillin_probe then fillin_signup (POST /v1/signup)
for a free 20-query trial, or fillin_payment_challenge then retry with
X-Payer-Address, X-Payer-Nonce, X-Payer-Signature (or Bearer).
POST /v1/probe for 1 free taste/IP/day.

Each result row carries the question, venue, close date, volume, and
a first-sight price snapshot embedded in `text`. Prices in the corpus
are point-in-time at first ingestion — for live pre-trade pricing,
follow the `url` to the venue and read the current quote there.

Input Schema

TableJSON Schema

Name	Required	Description
`k`	No	1-20
`query`	Yes	Prediction-market / forecast query.
`cutoff`	Yes	Training cutoff as ISO-8601 date.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedMay 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description adds significant behavioral context beyond the annotations: it discloses the payment requirement, the point-in-time price snapshot, and the need to follow the URL for live prices. It also warns about payment_required errors and the trial flow. This complements the read-only and idempotent hints without contradiction.

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 description is concise and well-structured, front-loading the purpose and usage context, then providing details on payment and data caveats. Each sentence adds value, though the payment flow explanation could be seen as slightly lengthy. Overall, it earns a high score for clarity and focus.

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?

Given the tool's complexity (multi-venue, payment flow, data quirks), the description covers all necessary aspects: what it does, when to use it, payment handling, and data interpretation. It also provides guidance on alternative tools for auth. The presence of an output schema further reduces the need to explain return values.

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?

The description does not directly explain individual parameters beyond what the schema provides, but the schema already covers them well (100% coverage). The description adds context about the output (each row carries question, venue, etc.) but doesn't elaborate on `k`, `cutoff`, or `query` semantics. Baseline of 3 is appropriate.

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 description clearly states the tool queries active prediction markets across multiple venues, with specific example queries. It distinguishes itself from siblings by naming the venues and use cases, and the title reinforces the scope. The description is not a tautology and provides concrete context for when an agent would invoke it.

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?

It explicitly states when to use the tool ('when a user asks...') and includes alternative actions when payment is required, routing to sibling tools like fillin_probe and fillin_signup. It also mentions using the `url` for live pricing, providing clear guidance on post-call behavior. The description fully covers usage scenarios and alternatives.

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

All Fillin 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?