Tlacuilo

polymarket_markets

polymarket_markets

Read-only

Polymarket prediction markets matching a text query, or the top markets by 24-hour volume when no query is given. Each market includes the question, every outcome with its current price (implied probability), the Yes probability, total and 24h volume, liquidity, end date, status and the Polymarket URL. Source: Polymarket Gamma API. Price: $0.005 USDC per call (x402).

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

Input Schema

Name	Required	Description
`q`	No	Words to search in market questions and event titles (optional; without it the result is the top markets by 24h volume)
`limit`	No	Markets to return, 1-50 (default 10)
`active`	No	true returns only open markets (default); false includes closed and resolved ones

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description still adds real behavior beyond that: the upstream source (Polymarket Gamma API) and the $0.005 USDC-per-call x402 payment requirement, which is important pre-call context. It does not cover error behavior, rate limits, or whether results are cached/fresh.

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?

Two sentences, front-loaded with the retrieval mode and immediately followed by the selection rule when no query is supplied. The field enumeration and pricing note are dense but each clause carries information an agent needs.

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 helpfully enumerates the returned fields (question, outcomes with implied-probability prices, volumes, liquidity, end date, status, URL). Combined with cost and source disclosure, an agent has enough to call and interpret it; pagination semantics and error handling are the only omissions.

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 all three parameters (q, limit, active) are already documented, including the default-active behavior. The description's extra detail ('Yes probability', outcome prices) describes return values rather than parameter meaning, so it adds little parameter-level semantics beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb and resource: prediction markets on Polymarket, matched by query or top-by-24h-volume when no query. It also enumerates the returned fields, so an agent knows exactly what it gets. It does not distinguish itself from the singular sibling polymarket_market, leaving the agent to infer that this one is the search/list variant.

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?

Gives clear conditional usage: with q it searches market questions and event titles; without q it returns top markets by 24h volume. The 'active' default (open only) vs explicit false is also clarified. No explicit when-not guidance or reference to polymarket_market for single-market lookups.

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

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