MCP Paradex Server

Overview Schema Source Related Servers Score Discussions Admin

paradex_klines

Analyze historical price data for technical analysis and trading decisions. Calculate indicators, identify support/resistance levels, and backtest strategies using candlestick data.

Instructions

Analyze historical price patterns for technical analysis and trading decisions.

Use this tool when you need to:
- Perform technical analysis on historical price data
- Identify support and resistance levels from price history
- Calculate indicators like moving averages, RSI, or MACD
- Backtest trading strategies on historical data
- Visualize price action over specific timeframes

Candlestick data is fundamental for most technical analysis and trading decisions,
providing structured price and volume information over time.

Example use cases:
- Identifying chart patterns for potential entries or exits
- Calculating technical indicators for trading signals
- Determining volatility by analyzing price ranges
- Finding significant price levels from historical support/resistance
- Measuring volume patterns to confirm price movements

Input Schema

TableJSON Schema

Name	Required	Description
`market_id`	Yes	Market symbol to get klines for.
`resolution`	No	The time resolution of the klines.
`start_unix_ms`	Yes	Start time in unix milliseconds.
`end_unix_ms`	Yes	End time in unix milliseconds.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Implementation Reference

src/mcp_paradex/tools/market.py:367-427 (handler)

The main handler function for the 'paradex_klines' tool. It fetches historical OHLCV (kline) data from the Paradex API using the provided market symbol, resolution, and time range. Parses the raw API response into a list of OHLCV Pydantic models.

@server.tool(name="paradex_klines")
async def get_klines(
    market_id: Annotated[str, Field(description="Market symbol to get klines for.")],
    resolution: Annotated[
        KLinesResolutionEnum, Field(default=1, description="The time resolution of the klines.")
    ],
    start_unix_ms: Annotated[int, Field(description="Start time in unix milliseconds.")],
    end_unix_ms: Annotated[int, Field(description="End time in unix milliseconds.")],
    ctx: Context = None,
) -> list[OHLCV]:
    """
    Analyze historical price patterns for technical analysis and trading decisions.

    Use this tool when you need to:
    - Perform technical analysis on historical price data
    - Identify support and resistance levels from price history
    - Calculate indicators like moving averages, RSI, or MACD
    - Backtest trading strategies on historical data
    - Visualize price action over specific timeframes

    Candlestick data is fundamental for most technical analysis and trading decisions,
    providing structured price and volume information over time.

    Example use cases:
    - Identifying chart patterns for potential entries or exits
    - Calculating technical indicators for trading signals
    - Determining volatility by analyzing price ranges
    - Finding significant price levels from historical support/resistance
    - Measuring volume patterns to confirm price movements
    """
    try:
        # Get klines from Paradex
        client = await get_paradex_client()
        response = await api_call(
            client,
            "markets/klines",
            params={
                "symbol": market_id,
                "resolution": str(resolution),
                "start_at": start_unix_ms,
                "end_at": end_unix_ms,
            },
        )
        if "error" in response:
            raise Exception(response["error"])
        results = response["results"]
        list_of_ohlcv = [
            OHLCV(
                timestamp=result[0],
                open=result[1],
                high=result[2],
                low=result[3],
                close=result[4],
                volume=result[5],
            )
            for result in results
        ]
        return list_of_ohlcv
    except Exception as e:
        await ctx.error(f"Error fetching klines for {market_id}: {e!s}")
        raise e

src/mcp_paradex/tools/market.py:350-362 (schema)

Input resolution type (KLinesResolutionEnum) and output schema (OHLCV model) for the paradex_klines tool.

KLinesResolutionEnum = Literal[1, 3, 5, 15, 30, 60]


class OHLCV(BaseModel):
    """OHLCV data for a market."""

    timestamp: int
    open: float
    high: float
    low: float
    close: float
    volume: float

src/mcp_paradex/tools/market.py:367-367 (registration)
Registration of the paradex_klines tool using the FastMCP server decorator.
```
@server.tool(name="paradex_klines")
```

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.0Jan 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$defs": {
+    "OHLCV": {
+      "description": "OHLCV data for a market.",
+      "properties": {
+        "close": {
+          "title": "Close",
+          "type": "number"
+        },
+        "high": {
+          "title": "High",
+          "type": "number"
+        },
+        "low": {
+          "title": "Low",
+          "type": "number"
+        },
+        "open": {
+          "title": "Open",
+          "type": "number"
+        },
+        "timestamp": {
+          "title": "Timestamp",
+          "type": "integer"
+        },
+        "volume": {
+          "title": "Volume",
+          "type": "number"
+        }
+      },
+      "required": [
+        "timestamp",
+        "open",
+        "high",
+        "low",
+        "close",
+        "volume"
+      ],
+      "title": "OHLCV",
+      "type": "object"
+    }
+  },
+  "properties": {
+    "result": {
+      "items": {
+        "$ref": "#/$defs/OHLCV"
+      },
+      "title": "Result",
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "get_klinesOutput",
+  "type": "object"
+}

First observedAug 15, 2025

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool provides (historical candlestick data for technical analysis) and mentions use cases, but doesn't disclose important behavioral traits like whether this is a read-only operation, rate limits, authentication requirements, or what format the output takes. The description adds value but leaves significant gaps for a tool that fetches historical market data.

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 description is front-loaded with a clear purpose statement, but contains redundancy (multiple bullet points that essentially restate technical analysis applications) and could be more concise. The 'Example use cases' section largely repeats concepts from the 'Use this tool when you need to' section, suggesting some sentences don't earn their place.

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?

Given that an output schema exists (per context signals), the description doesn't need to explain return values. For a data retrieval tool with good parameter documentation in the schema, the description provides adequate context about what the tool does and when to use it. However, with no annotations, it could better address behavioral aspects like data freshness, limitations, or error conditions.

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?

With 100% schema description coverage, the input schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it doesn't explain the significance of 'resolution' values, how to interpret market_id format, or provide guidance on time range selection. This meets the baseline for high schema coverage.

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 clearly states the tool's purpose as analyzing historical price patterns for technical analysis and trading decisions, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'paradex_trades' or 'paradex_market_summaries' which might also provide price-related data, though the focus on candlestick data and technical analysis provides some implicit distinction.

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

Usage Guidelines4/5

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

The description provides clear usage contexts with a bulleted list of when to use the tool (technical analysis, identifying support/resistance, calculating indicators, backtesting, visualizing). It doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, but the context is well-defined and helpful for an agent.

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