Skip to main content
Glama

get_kline

Retrieve candlestick (K-line) data for a specific trading pair and time interval. Specify category, symbol, interval, and optional start, end, and limit parameters to analyze market trends and price movements.

Instructions

Get K-line (candlestick) data

Args:
    category (str): Category (spot, linear, inverse, etc.)
    symbol (str): Symbol (e.g., BTCUSDT)
    interval (str): Time interval (1, 3, 5, 15, 30, 60, 120, 240, 360, 720, D, W, M)
    start (Optional[int]): Start time in milliseconds
    end (Optional[int]): End time in milliseconds
    limit (int): Number of records to retrieve

Returns:
    Dict: K-line data

Example:
    get_kline("spot", "BTCUSDT", "1h", 1625097600000, 1625184000000, 100)

Reference:
    https://bybit-exchange.github.io/docs/v5/market/kline

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryYesCategory (spot, linear, inverse, etc.)
endNoEnd time in milliseconds
intervalYesTime interval (1, 3, 5, 15, 30, 60, 120, 240, 360, 720, D, W, M)
limitNoNumber of records to retrieve
startNoStart time in milliseconds
symbolYesSymbol (e.g., BTCUSDT)

Implementation Reference

  • The primary MCP tool handler for 'get_kline'. Decorated with @mcp.tool(), uses Pydantic Field for input schema/validation, calls BybitService.get_kline, handles errors and returns the API response.
    @mcp.tool()
    def get_kline(
        category: str = Field(description="Category (spot, linear, inverse, etc.)"),
        symbol: str = Field(description="Symbol (e.g., BTCUSDT)"),
        interval: str = Field(description="Time interval (1, 3, 5, 15, 30, 60, 120, 240, 360, 720, D, W, M)"),
        start: Optional[int] = Field(default=None, description="Start time in milliseconds"),
        end: Optional[int] = Field(default=None, description="End time in milliseconds"),
        limit: int = Field(default=200, description="Number of records to retrieve")
    ) -> Dict:
        """
        Get K-line (candlestick) data
    
        Args:
            category (str): Category (spot, linear, inverse, etc.)
            symbol (str): Symbol (e.g., BTCUSDT)
            interval (str): Time interval (1, 3, 5, 15, 30, 60, 120, 240, 360, 720, D, W, M)
            start (Optional[int]): Start time in milliseconds
            end (Optional[int]): End time in milliseconds
            limit (int): Number of records to retrieve
    
        Returns:
            Dict: K-line data
    
        Example:
            get_kline("spot", "BTCUSDT", "1h", 1625097600000, 1625184000000, 100)
    
        Reference:
            https://bybit-exchange.github.io/docs/v5/market/kline
        """
        try:
            result = bybit_service.get_kline(category, symbol, interval, start, end, limit)
            if result.get("retCode") != 0:
                logger.error(f"Failed to get K-line data: {result.get('retMsg')}")
                return {"error": result.get("retMsg")}
            return result
        except Exception as e:
            logger.error(f"Failed to get K-line data: {e}", exc_info=True)
            return {"error": str(e)}
  • Helper method in BybitService class that prepares parameters and calls the pybit.unified_trading.HTTP client's get_kline method to fetch actual K-line data from Bybit API.
    def get_kline(self, category: str, symbol: str, interval: str,
                  start: Optional[int] = None, end: Optional[int] = None,
                  limit: int = 200) -> Dict:
        """
        Get K-line data
        
        Args:
            category: Category (spot, linear, inverse, etc.)
            symbol: Symbol (e.g., BTCUSDT)
            interval: Time interval (1, 3, 5, 15, 30, 60, 120, 240, 360, 720, D, W, M)
            start: Start time (millisecond timestamp)
            end: End time (millisecond timestamp)
            limit: Number of records to retrieve
            
        Returns:
            Dict: K-line data
        """
        try:
            params = {
                "category": category,
                "symbol": symbol,
                "interval": interval,
                "limit": limit
            }
            
            if start:
                params["start"] = start
            if end:
                params["end"] = end
                
            response = self.client.get_kline(**params)
            return response
            
        except Exception as e:
            logger.error(f"Failed to get K-line data: {str(e)}")
            return {"error": str(e)}
  • src/server.py:92-92 (registration)
    The @mcp.tool() decorator registers the get_kline function as an MCP tool.
    @mcp.tool()
  • Pydantic Field definitions provide the input schema and descriptions for the MCP tool parameters.
        category: str = Field(description="Category (spot, linear, inverse, etc.)"),
        symbol: str = Field(description="Symbol (e.g., BTCUSDT)"),
        interval: str = Field(description="Time interval (1, 3, 5, 15, 30, 60, 120, 240, 360, 720, D, W, M)"),
        start: Optional[int] = Field(default=None, description="Start time in milliseconds"),
        end: Optional[int] = Field(default=None, description="End time in milliseconds"),
        limit: int = Field(default=200, description="Number of records to retrieve")
    ) -> Dict:
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 implies this is a read-only operation ('Get'), but doesn't explicitly state whether it requires authentication, has rate limits, or what happens with invalid inputs. The example and reference link add some context, but key behavioral traits like error handling or performance characteristics are missing, making this adequate but incomplete.

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

Conciseness4/5

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

The description is well-structured with clear sections (Args, Returns, Example, Reference) and front-loads the core purpose. However, the parameter descriptions are redundant with the schema, and the example could be more concise. Overall, it's efficient but has minor verbosity in repeating schema details.

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 tool's moderate complexity (6 parameters, no output schema, no annotations), the description is partially complete. It covers the basic purpose and parameters but lacks details on return format (beyond 'Dict'), error conditions, authentication needs, and differentiation from siblings. The reference link helps, but the description alone doesn't provide full context for reliable agent use.

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%, meaning all parameters are documented in the input schema. The description repeats parameter information verbatim from the schema without adding meaningful context like valid symbol formats, interval interpretations (e.g., 'D' for day), or how start/end times interact with the limit. This meets the baseline for high schema coverage but doesn't enhance understanding beyond what's already structured.

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 'Get K-line (candlestick) data' with a specific verb ('Get') and resource ('K-line data'), making the function immediately understandable. However, it doesn't explicitly differentiate this tool from potential sibling tools that might also retrieve market data, such as 'get_tickers' or 'get_orderbook', which could provide overlapping functionality.

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 like 'get_tickers' or 'get_orderbook', nor does it mention prerequisites or context for usage. The example and reference link are helpful but don't constitute explicit usage guidelines, leaving the agent to infer when this specific data retrieval method is appropriate.

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

Related 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/dlwjdtn535/mcp-bybit-server'

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