Polymarket MCP Server

get_trending_markets

Get top prediction markets by trading volume for a chosen period to focus on active opportunities.

Instructions

Get markets with highest trading volume in specified timeframe. Returns top markets sorted by volume.

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

Input Schema

Name	Required	Description	Default
`limit`	No	Number of markets to return (default 10)
`timeframe`	No	Time period for volume calculation	24h

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 22, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It states it returns top markets sorted by volume, but does not disclose response structure (e.g., whether volume is included, market IDs only), pagination, or any side effects. Basic behavior is clear, but deeper transparency is missing.

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 with no filler. The core purpose is front-loaded, and the return behavior is stated efficiently. Perfectly sized for a simple list tool.

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?

Given the low complexity and full schema coverage, the description covers the essential purpose and return type. It could mention defaults or differentiate from volume-specific tools, but it is sufficient for an agent to call it correctly.

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%, with both parameters (limit, timeframe) described. The description adds no extra meaning beyond 'specified timeframe', which already maps to the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 states a clear verb ('Get') and resource ('markets') with specific qualifiers: highest trading volume and specified timeframe. It distinguishes from siblings like get_featured_markets (curated) and get_closing_soon_markets (time-based) by focusing on volume ranking.

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?

The description implies usage (when you want top markets by volume over a timeframe) but does not mention alternatives or when not to use it. No explicit exclusions or routing to other tools, despite many sibling list tools.

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