Skip to main content
Glama
Sign In
mcp-server-polymarket

mcp-server-polymarket

by tukorama
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

List trades

list_trades
Read-onlyIdempotent

Fetch trades for a wallet, event, market, or the entire exchange, newest first, with filters and cursor-based pagination.

Instructions

Trades for a wallet, markets, events, or the whole exchange, newest first. Re-send the same filters with each cursor.

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

Input Schema

NameRequiredDescriptionDefault
endNoISO 8601 time, e.g. 2026-11-01 or 2026-11-01T12:00:00Z, or epoch seconds.
sideNo
userNoA wallet; empty is the global feed.
limitNoRows per page.
startNoISO 8601 time, e.g. 2026-11-01 or 2026-11-01T12:00:00Z, or epoch seconds.
cursorNonext_cursor from the previous page. Empty starts at the top.
min_usdNoOnly trades at least this big.
event_idsNoUp to 20 event ids.
condition_idsNoUp to 20 condition ids.
include_maker_sideNoAlso the maker row of each fill.

Output Schema

NameRequiredDescriptionDefault
noteNo
countNo
itemsNo
has_moreNo
next_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so safety needs no restating. The description contributes real behavioral value with the 'newest first' ordering and the cursor rule that filters must be re-sent unchanged, which prevents a silent page-corruption bug. It stops short of noting that an empty user yields the global exchange feed (that is only in the schema) or anything about rate limits or page-size ceilings.

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 tight sentences, no filler. Scope comes first, then the pagination contract, so the agent gets the routing decision before the mechanical detail.

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?

For a 10-parameter read-only list tool with 90% schema coverage and an output schema covering return shape, the description supplies the two things structured fields cannot: default ordering and the cursor/filter invariant. Only the absence of a sibling-disambiguation hint (perps vs. spot trades) keeps it below a 5.

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 90%, so the schema already explains start/end formats, cursor provenance, limit bounds, min_usd, and the 20-item caps. The description adds only the semantics of the top-level scoping options and the invariant that cursor re-use requires identical filters. Baseline 3 applies when the schema carries the detail.

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?

The description names the resource (trades) and enumerates the four eligible scopes (wallet, markets, events, whole exchange) plus ordering (newest first). It is a clear verb+resource statement, though it never explicitly distinguishes itself from lookalike siblings such as list_perps_trades or list_perps_public_fills.

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?

Scope usage is implied by the opening clause — pass a wallet, market, event ids, or nothing for the global feed — and the second sentence gives a concrete pagination protocol. But there is no explicit when-not guidance and no routing to the perps trade siblings, which is the most likely confusion given the catalog.

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

Deploy Server

Other Tools