Skip to main content
Glama
qeinfinity

Binance MCP Server

get_klines

Retrieve historical candlestick data for Binance trading pairs to analyze price movements and market trends across specified time intervals.

Instructions

Get historical candlestick data

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYesTrading pair symbol (e.g., BTCUSDT)
typeYesMarket type
intervalYesKline/candlestick chart interval
limitNoNumber of klines to retrieve (default 500, max 1000)

Implementation Reference

  • Core implementation of the get_klines tool. Fetches historical candlestick (kline) data from Binance REST API for spot or futures markets. Uses axios with retry logic via executeWithRetry, handles parameters and returns raw API response data.
    public async getKlines(
      symbol: string,
      type: 'spot' | 'futures',
      interval: string,
      limit?: number
    ): Promise<any> {
      try {
        logger.info(`Getting ${type} klines for ${symbol}`);
        const baseUrl = type === 'spot' ? config.SPOT_REST_URL : config.FUTURES_REST_URL;
        const response = await this.executeWithRetry(() =>
          this.axiosInstance.get(`${baseUrl}/klines`, {
            params: {
              symbol: symbol.toUpperCase(),
              interval,
              limit: limit || 500
            }
          })
        );
        logger.info('Successfully fetched klines data');
        return response.data;
      } catch (error) {
        logger.error('Error fetching klines:', error);
        throw new APIError('Failed to fetch klines data', error as Error);
      }
    }
  • src/index.ts:108-135 (registration)
    Registers the get_klines tool with the MCP server in the ListTools handler, defining its name, description, and detailed input schema matching KlineParams.
    {
      name: "get_klines",
      description: "Get historical candlestick data",
      inputSchema: {
        type: "object",
        properties: {
          symbol: { 
            type: "string", 
            description: "Trading pair symbol (e.g., BTCUSDT)" 
          },
          type: { 
            type: "string", 
            enum: ["spot", "futures"], 
            description: "Market type" 
          },
          interval: {
            type: "string",
            enum: ["1m", "5m", "15m", "30m", "1h", "4h", "1d", "1w", "1M"],
            description: "Kline/candlestick chart interval"
          },
          limit: {
            type: "number",
            description: "Number of klines to retrieve (default 500, max 1000)"
          }
        },
        required: ["symbol", "type", "interval"]
      }
    },
  • MCP CallToolRequest handler for get_klines. Validates input using isKlineParams type guard, extracts parameters, calls the BinanceRestConnector.getKlines implementation, and formats response as JSON text.
    case "get_klines": {
      if (!isKlineParams(request.params.arguments)) {
        throw new Error('Invalid kline parameters');
      }
      const { symbol, type, interval, limit } = request.params.arguments;
      const data = await restConnector.getKlines(symbol, type, interval, limit);
      return {
        content: [{
          type: "text",
          text: JSON.stringify(data, null, 2)
        }]
      };
    }
  • TypeScript interface defining the input parameters for the get_klines tool, used for validation.
    export interface KlineParams {
      symbol: string;
      type: 'spot' | 'futures';
      interval: string;
      limit?: number;
    }
  • Type guard function for validating get_klines input parameters against KlineParams interface.
    export function isKlineParams(params: any): params is KlineParams {
      return (
        typeof params === 'object' &&
        typeof params.symbol === 'string' &&
        (params.type === 'spot' || params.type === 'futures') &&
        typeof params.interval === 'string' &&
        (params.limit === undefined || typeof params.limit === 'number')
      );
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get historical candlestick data', implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, error handling, or data freshness, which are critical for a financial data tool.

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?

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly, which is ideal for conciseness.

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

Completeness2/5

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

Given the complexity of financial data retrieval and the lack of annotations and output schema, the description is insufficient. It doesn't explain return values, error conditions, or behavioral traits like pagination or data limits, leaving significant gaps for agent understanding.

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?

The schema description coverage is 100%, with all parameters well-documented in the schema itself. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or providing examples, so it meets the baseline for high coverage without compensating value.

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 verb 'Get' and the resource 'historical candlestick data', which is specific and unambiguous. However, it doesn't distinguish this tool from sibling tools like 'get_market_data' or 'subscribe_market_data', which might also provide market-related information.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_market_data' or 'subscribe_market_data', nor does it specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from context alone.

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/qeinfinity/binance-mcp-server'

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