Indian Stock Exchange API2 MCP Server

historical_data

Retrieve historical stock price data for Indian companies listed on NSE and BSE to analyze market trends and performance over time.

Instructions

Endpoint: /historical_data - Method: GET - Query Parameters: - stock_name (required): string - period (optional): string, default is \

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": {
      "stock_name": "<stock_name>"
    },
    "name": "historical_data"
  }
}

Input Schema

Name	Required	Description
`stock_name`	Yes	Example value: tcs
`period`	No	Example value:
`filter`	No	Example value:

Implementation Reference

server.py:54-61 (registration)
The FastMCP server is initialized using the `from_openapi` method, which automatically registers tools based on the OpenAPI specification. The `historical_data` tool is defined within the `OPENAPI_SPEC` string starting at line 46.
```
# 从 OpenAPI 规范创建 FastMCP 服务器
openapi_dict = json.loads(OPENAPI_SPEC)
mcp = FastMCP.from_openapi(
    openapi_spec=openapi_dict,
    client=client,
    name="indian_stock_exchange_api2",
    version=__version__
)
```

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Mar 25, 2026

TDQS

C2/5.0

Behavior2/5

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

No annotations provided, so the description carries full disclosure burden. It only reveals the HTTP method (GET), implying a read operation, but fails to specify the data format returned, what constitutes a valid period string, rate limits, or error behavior. The default value description is truncated ('default is \"'), leaving critical behavioral context missing.

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

Conciseness2/5

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

The formatting is garbled (markdown bullets merged into a single line) and the text appears truncated mid-value. While brief, the structure is poor for an AI reader, mixing endpoint syntax with parameter documentation without clear intent hierarchy.

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?

Lacking output schema and annotations, a data retrieval tool needs description of return values (OHLCV? adjusted prices? splits/dividends?). The description omits what 'historical data' encompasses, pagination behavior, and time range limits, leaving critical gaps for invocation planning.

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 baseline is 3. The description merely lists parameters already documented in the schema without adding semantic depth (e.g., explaining period formats like '1Y' vs '5Y', or filter syntax). The schema examples are empty strings for optional parameters, which the description doesn't compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description provides technical endpoint details (GET /historical_data) and parameter listings but fails to state what business function it performs (e.g., 'retrieves historical price data'). It restates implementation metadata rather than describing the tool's purpose or distinguishing it from siblings like historical_stats.

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

Usage Guidelines1/5

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

No guidance provided on when to use this tool versus alternatives (e.g., get_stock_data_by_name for current prices, historical_stats for aggregates). No mention of prerequisites, data availability constraints, or typical use cases.

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

Deploy Server