Skip to main content
Glama

Get market closing line

get_market_close
Read-onlyIdempotent

The closing line of one sports or esports market: the price Polymarket's own price-history series recorded for each outcome in the last minute bucket that ended at or before kickoff, read once after the market settles and stored unchanged. Not a midpoint and not a last trade. outcomes[0] is the YES leg as stored; outcomes[1] is the NO leg, 1 minus the YES price (derived_from_yes true). status is measured with both legs; pending when no close is stored yet (the game has not started, the market has not settled, or the capture has not reached it; it measures markets up to 30 days after kickoff); or unavailable with unavailable_reason when none will be served. A missing close is never 0. anchor_stale is true when kickoff has moved more than lookback_seconds since capture. The same close measures the clv object on each large trade.

Args:

  • condition_id (string, required): Raw provider condition_id or the mkt_-prefixed market id

Returns: condition_id, status, unavailable_reason, game_start_time, close_anchor_at, close_anchor_source, anchor_stale, lookback_seconds, observed_at, observation_window_seconds, price_source, basis_version, captured_at, outcomes (outcome_index, outcome, token_id, close_price, derived_from_yes) and meta.

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_id": "<condition_id>"
    },
    "name": "get_market_close"
  }
}

Input Schema

NameRequiredDescriptionDefault
condition_idYesRaw provider condition_id or the mkt_-prefixed market id

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / $defs / ResponseMeta / properties / continued_from_generation
      Added value: +{
      +  "type": "integer"
      +}
  2. Added

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already declare this a read-only, idempotent, non-destructive call, and the description still adds substantial behavioural context: the value is captured once and stored unchanged, pending applies before start / before settlement / up to 30 days after kickoff, unavailable carries a reason, a missing close is never 0, and anchor_stale marks kickoff drift beyond lookback_seconds. That is genuine disclosure of edge-case semantics an agent could not get from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core definition is front-loaded and information-dense, but the passage is a run of long parenthetical clauses and two trailing sections (Args, Returns) that duplicate the input and output schemas rather than earning their space. Trimming those duplicates would keep the useful semantics and roughly halve the length.

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?

For a single-parameter read tool, the description covers the value's provenance, capture timing, all status branches, the never-zero rule, and the anchor_stale/lookback condition. Combined with an output schema and read-only annotations, nothing an agent needs to call and interpret it correctly is missing.

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?

There is a single parameter at 100% schema coverage, and the Args section restates the schema text verbatim ("Raw provider condition_id or the mkt_-prefixed market id") without adding format, validation, or lookup guidance. With the schema already doing the work, this hits the baseline rather than adding meaning.

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 states exactly what is returned: the closing line of one sports/esports market, defined as the price recorded in the last minute bucket ending at or before kickoff, and explicitly negates two adjacent concepts ("Not a midpoint and not a last trade"). The resource and its scope are unambiguous, but it never names a sibling tool (e.g. get_market_candles, get_market_snapshot) to route the agent, which keeps it short of a 5.

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?

Usage is implied rather than instructed: the agent learns the close is "read once after the market settles" and that it backs the clv object on large trades, which hints at when the value is meaningful. However there is no explicit when-to-use/when-not-to-use statement and no comparison against the many sibling market-data tools, so the agent must infer selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.