Skip to main content
Glama
mcp-server-polymarket

mcp-server-polymarket

Get open interest

get_open_interest
Read-onlyIdempotent

Retrieve open interest in USD for up to 20 Polymarket markets to see how much money currently backs their prices.

Instructions

Open interest in USD for up to 20 markets: the money currently behind their prices.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "condition_ids": "<condition_ids>"
    },
    "name": "get_open_interest"
  }
}

Input Schema

NameRequiredDescriptionDefault
condition_idsYes

Output Schema

NameRequiredDescriptionDefault
totalNo
marketsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/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 needs no restatement. The description adds the genuinely useful facts that values are denominated in USD and that the batch is capped, but says nothing about behavior on invalid or unknown condition IDs, partial failures, or whether the response is a map keyed by market.

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?

A single front-loaded sentence pairing the concrete output (open interest in USD) with scope and a short gloss. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a read-only single-parameter tool, full annotations, and an output schema that covers return values, most informational burden is already met. The remaining gap is operational: no hint on sourcing valid condition IDs, which matters because the schema gives no format guidance whatsoever.

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 0%, so the description must carry the parameter's meaning; it does partially by framing the array as 'markets', which tells the agent each string identifies a market. However, it never explains what a condition_id is or where to obtain one, which is the main blocking unknown for a caller.

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?

Names the specific resource (open interest), the unit (USD), and the scope (up to 20 markets), plus a plain-language gloss of what open interest means. An agent can tell this apart from price/volume tools without opening the schema, though the verb is only implied by the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this versus related tools such as get_market_trading_info or get_order_books, and no prerequisites (e.g., that a market must exist or be active). Usage must be inferred entirely from the name.

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