Skip to main content
Glama
mcp-server-polymarket

mcp-server-polymarket

Get a market

get_market
Read-onlyIdempotent

Retrieve a single Polymarket market by slug, token ID, market ID, or condition ID, including outcomes, prices, tick size, fees, rewards, and full rules.

Instructions

One market with its outcomes, prices, token ids, tick size, fees, rewards and full rules (description). Give exactly one identifier.

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_market"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNoMarket URL slug.
token_idNoAn outcome token id.
market_idNoNumeric Gamma market id.
condition_idNo0x condition id.

Output Schema

NameRequiredDescriptionDefault
idYes
urlNo
slugNo
tagsNo
spreadNo
statusNo
volumeNo
best_askNo
best_bidNo
end_dateNo
event_idNo
neg_riskNo
outcomesNo
protocolNo
questionNo
liquidityNo
tick_sizeNo
event_slugNo
start_dateNo
volume_24hNo
closed_timeNo
descriptionNo
question_idNo
rfq_enabledNo
condition_idNo
fee_scheduleNo
fees_enabledNo
min_order_sizeNo
accepting_ordersNo
group_item_titleNo
last_trade_priceNo
rewards_min_sizeNo
resolution_sourceNo
rewards_max_spreadNo
one_day_price_changeNo
uma_resolution_statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the one real behavioral constraint — supply exactly one identifier — but does not say what happens if zero or several are given (error? precedence?).

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 short sentences, both front-loaded: the return payload first, then the calling constraint. No filler, no repetition of the title.

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?

An output schema exists, so the return shape need not be explained, and the annotations carry the safety semantics. What remains for a read-only single-entity lookup — what it returns at a high level and the one-identifier constraint — is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each of slug, token_id, market_id and condition_id is already documented, and the baseline would be a 3. The description earns above baseline by supplying the one-of/XOR rule that the schema cannot express: all four parameters are optional with no enforcement, so "exactly one identifier" is genuinely new and actionable information.

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 a specific verb and resource ("One market") and enumerates the payload the caller gets back — outcomes, prices, token ids, tick size, fees, rewards, rules. That is clear enough to separate it from the list-style siblings, but it never names a related lookup such as get_market_trading_info, so differentiation from siblings is left implicit.

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?

"Give exactly one identifier" implies the lookup context (retrieve a single market's metadata) but is phrased as a constraint rather than a when-to-use rule. There is no statement of when a caller should prefer this over another market-related tool, and no guidance on what to do when no identifier is available.

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