Skip to main content
Glama
PaulieB14

graph-polymarket-mcp

get_price_history

Retrieve historical price points for a Polymarket outcome token to analyze trends and create charts. Supports customizable intervals and data point counts.

Instructions

Get historical price data for a Polymarket outcome token. Returns time-series price points for charting and trend analysis.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenIdYesCLOB token ID
intervalNoTime interval: 1m, 5m, 1h, 6h, 1d, 1w, or max1d
fidelityNoNumber of data points to return (1-500)

Implementation Reference

  • src/index.ts:1206-1243 (registration)
    Tool 28 'get_price_history' registration in the MCP server. Defined with inputSchema requiring tokenId, interval (1m/5m/1h/6h/1d/1w/max), and fidelity (1-500). Handler calls getClobPriceHistory() and transforms the response.
    server.registerTool(
      "get_price_history",
      {
        description:
          "Get historical price data for a Polymarket outcome token. Returns time-series price points for charting and trend analysis.",
        inputSchema: {
          tokenId: z.string().describe("CLOB token ID"),
          interval: z
            .enum(["1m", "5m", "1h", "6h", "1d", "1w", "max"])
            .default("1d")
            .describe("Time interval: 1m, 5m, 1h, 6h, 1d, 1w, or max"),
          fidelity: z
            .number()
            .min(1)
            .max(500)
            .default(60)
            .describe("Number of data points to return (1-500)"),
        },
      },
      async ({ tokenId, interval, fidelity }) => {
        try {
          const data = await getClobPriceHistory(tokenId, interval, fidelity);
          const history = (data.history ?? []).map((p) => ({
            timestamp: p.t,
            date: new Date(p.t * 1000).toISOString(),
            price: p.p,
          }));
          return textResult({
            tokenId,
            interval,
            pointCount: history.length,
            history,
          });
        } catch (error) {
          return errorResult(error);
        }
      }
    );
  • getClobPriceHistory() — the actual implementation function that calls the Polymarket CLOB API at /prices-history endpoint. Takes tokenId, interval, and fidelity; returns { history: Array<{ t: number, p: number }> }.
    export async function getClobPriceHistory(
      tokenId: string,
      interval: string = "1d",
      fidelity: number = 60
    ): Promise<{ history: Array<{ t: number; p: number }> }> {
      return fetchJson<{ history: Array<{ t: number; p: number }> }>(
        `${CLOB_BASE}/prices-history?market=${encodeURIComponent(tokenId)}&interval=${interval}&fidelity=${fidelity}`
      );
    }
  • Input schema for get_price_history: tokenId (string), interval (enum: 1m/5m/1h/6h/1d/1w/max, default 1d), fidelity (number 1-500, default 60).
      inputSchema: {
        tokenId: z.string().describe("CLOB token ID"),
        interval: z
          .enum(["1m", "5m", "1h", "6h", "1d", "1w", "max"])
          .default("1d")
          .describe("Time interval: 1m, 5m, 1h, 6h, 1d, 1w, or max"),
        fidelity: z
          .number()
          .min(1)
          .max(500)
          .default(60)
          .describe("Number of data points to return (1-500)"),
      },
    },
  • fetchJson<T>() — generic HTTP helper used by getClobPriceHistory to make requests to the CLOB API with JSON parsing and error handling.
    async function fetchJson<T>(url: string): Promise<T> {
      const response = await fetch(url, {
        headers: { Accept: "application/json" },
      });
      if (!response.ok) {
        throw new PolymarketApiError(
          `HTTP ${response.status}: ${response.statusText}`,
          response.status,
          url
        );
      }
      return response.json() as Promise<T>;
    }
Behavior2/5

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

With no annotations, the description carries full burden. It only says 'returns time-series price points' but omits behavioral traits like read-only nature, time range limits, or response format details.

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, front-loaded with purpose, no extraneous information. Highly concise and well-structured.

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?

Given the simplicity of the tool (3 params, no output schema), the description is adequate but lacks details on return fields or any time range constraints that would fully inform an agent.

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 descriptions for all parameters. The tool description adds no extra meaning beyond what the schema provides, so baseline score of 3 applies.

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?

Clearly states 'Get historical price data for a Polymarket outcome token' with the specific resource and purpose ('charting and trend analysis'). Distinguishes from sibling tools like get_live_prices or get_market_data.

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 usage guidance provided. Does not explain when to use this tool vs alternatives like get_live_prices for current prices or get_oi_history for open interest.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PaulieB14/graph-polymarket-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server