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.

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

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses critical behavioral traits beyond the annotations: prices are point-in-time at first ingestion, and users must follow the URL for live pre-trade pricing. It also specifies what each result row contains (question, venue, close date, volume, price snapshot). This adds significant context about data freshness and limitations, well above the annotation baseline.

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?

The description is compact and well-structured, with four sentences each adding value: scope, usage triggers, result shape, and price caveat. No filler or redundancy. It front-loads the core purpose and keeps supporting details brief, earning a top score for conciseness.

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 read-only search tool with annotations (readOnlyHint, openWorldHint, idempotentHint) and an output schema, the description covers essential operational details: what results contain, the point-in-time nature of prices, and how to get live prices. It lacks nothing critical for correct invocation or interpretation, making it contextually complete.

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 description coverage is 100%, with each parameter already documented in the schema (query, cutoff, k). The tool description does not add additional parameter-level meaning beyond what the schema provides. It mentions related concepts (prices, URLs) but does not elaborate on parameter usage. Baseline 3 is appropriate since schema carries the parameter burden.

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 identifies the tool's purpose: searching active prediction markets across four named venues (Polymarket, Kalshi, Manifold, Metaculus). It also provides concrete usage examples ('is there a market on X', 'what odds is the market giving Y') that distinguish it from generic search tools. The resource and scope are explicit and differentiate it from siblings like fillin_market_search.

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?

The description provides explicit when-to-use guidance: 'Use when a user asks...' and 'before any agent action that should be informed by a market price.' It does not mention when-not-to-use or name alternative tools, but the context is clear and actionable. This matches the 'clear context, no exclusions' level.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation2/5

Several tools overlap significantly: fillin_query, glyph_search, and retrieve_auto all perform post-cutoff retrieval and differ only in output substrate, and fillin_health and fillin_stats both report corpus stats. This creates ambiguity for agents choosing between them.

Naming Consistency3/5

Tool names mix three conventions: fillin_* (fillin_query, fillin_mint), query_* (query_cves, query_papers), and bare names (encode, glyph_search, retrieve_auto). While readable and mostly snake_case, the lack of a uniform prefix or verb pattern makes naming inconsistent.

Tool Count4/5

14 tools is within the acceptable range for a multi-feature server, but there is some redundancy (two health/stats tools, three retrieval variants), making the count feel slightly inflated.

Completeness5/5

The server covers retrieval (text/glyph/auto), encoding, marketplace operations (mint, search, buy), and domain-specific queries (CVEs, frontier AI, markets, papers), with no obvious missing capabilities.

Resources

Need Help?