This server provides read-only access to Indian market and regulatory data from official sources: NSE end-of-day data, NIFTY index constituents, AMFI mutual fund data, and a sample of SEBI enforcement orders.
nse_eod_quote — Get settled end-of-day OHLCV for an NSE stock (e.g. RELIANCE), optionally for a specific trade date; defaults to the latest published trading day.
nse_eod_history — Get a daily OHLCV series for one NSE symbol over a date range (capped at 120 calendar days).
list_nse_indices — List the NSE/NIFTY indices for which constituent data is available.
nse_index_constituents — Get constituent stocks for an index such as 'NIFTY 50' or 'NIFTY BANK'; weights are not available.
mf_search_schemes — Search ~14,000 Indian mutual fund schemes by name, AMC, or category; returns scheme codes, latest NAV, and metadata.
mf_scheme — Get latest NAV and metadata for a specific AMFI scheme code.
mf_nav_history — Get historical NAV series for a mutual fund, optionally bounded by start/end dates.
sebi_search_orders — Search a local sample of SEBI enforcement orders by text, entity, or year; the corpus is only a sample, so absence of results does not prove no orders exist.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@indian-markets-mcp Get the NSE end-of-day quote for Infosys"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server exposing Indian market and regulatory data from official, openly published sources — NSE's bhavcopy archive, NIFTY Indices constituent files, AMFI's industry NAV file, and a local SEBI enforcement-order corpus.
Built against MCP Python SDK v2 (mcp >= 2.0.0).
The server's real tools/list response, fetched in-process with the MCP SDK client (no upstream calls). Regenerate: python scripts/render_tool_list.py.
There are already several Indian-market MCP servers (see
docs/SURVEY.md for the full landscape review). Almost all of
them wrap either yfinance or a paid third-party API, and they compete on live
quote coverage.
This server deliberately does not compete there. It covers what the others do not: official primary sources with a clean terms position, plus regulatory data. Where a source will not permit automated access, this server says so and omits the tool rather than working around the block.
Related MCP server: mftool-mcp
Tool | Source | Status |
| NSE bhavcopy archive | Working — end-of-day only |
| NSE bhavcopy archive | Working — capped at 120 days |
| static list | Working |
| niftyindices.com CSV | Working — no weights |
| AMFI | Working — ~14,200 schemes |
| AMFI | Working |
| mfapi.in | Working |
| local corpus | Working — 25-order sample |
Deliberately not implemented, with reasons:
Live/intraday quotes. nseindia.com/api/quote-equity returns
403 Access Denied to non-browser clients (verified 2026-08-06). Reaching it
means forging browser headers to defeat an access control the exchange put
there on purpose. Not done.
Index constituent weights. NSE publishes weights only in factsheet PDFs
and a paid data product. The free constituent CSVs carry no weight column, so
the tool reports weights_available: false rather than estimating.
Corporate actions (dividends, splits, bonuses). The spec asked for these. No free source was found that serves them to an automated client under terms that permit it — NSE's corporate-actions endpoint sits behind the same 403. Not implemented rather than half-implemented. See docs/SOURCES.md.
Not yet published to PyPI. From a checkout:
git clone https://github.com/siddharthgaur1/indian-markets-mcp
cd indian-markets-mcp
python -m venv .venv && .venv/bin/pip install -e .{
"mcpServers": {
"indian-markets": {
"command": "/absolute/path/to/indian-markets-mcp/.venv/bin/indian-markets-mcp"
}
}
}On Windows use .venv\\Scripts\\indian-markets-mcp.exe.
The SEBI tool additionally needs a corpus; point it at one with:
"env": { "INDIAN_MARKETS_MCP_SEBI_DB": "/path/to/sebi_orders.db" }Every other tool works with no API keys and no configuration.
No fabricated data. A dead upstream raises a clear error. Missing values
stay null; they are never coerced to zero.
Caching. On-disk SQLite at ~/.cache/indian-markets-mcp/. Settled
bhavcopies are cached permanently because they are immutable.
Rate limiting. One-second minimum interval per host, enforced centrally, with exponential backoff. Not left to the caller.
Stale-cache fallback. If an upstream is down and a stale cached copy exists, it is served rather than failing — and never presented as live.
.venv/bin/pytest # offline tests only (default)
.venv/bin/pytest -m live # additionally hits real upstream sourcesNetwork-dependent tests are marked live and deselected by default, so CI does
not depend on NSE being reachable.
MIT. Data served by this tool belongs to its publishers (NSE, NIFTY Indices, AMFI, SEBI) and is subject to their terms — see docs/SOURCES.md.
Names of the NSE/NIFTY indices whose constituents this server can return.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering safety and mutability. The description adds the useful context that the returned names are limited to indices whose constituents the server can return, but it does not describe response format, ordering, or potential emptiness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that leads with the resource and directly states what the tool returns. No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless discovery tool with strong annotations, the description is complete. It tells the agent exactly what the tool returns and why that matters: indices whose constituents this server can support. No output schema exists, but the description adequately describes the return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%, so there is no parameter documentation burden. The baseline of 4 applies because no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns names of NSE/NIFTY indices, which is a specific resource and scope. It doesn't explicitly name a sibling tool, but the phrase 'whose constituents this server can return' distinguishes it from nse_index_constituents, which likely returns the constituents themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is a discovery endpoint for enumerating supported indices before requesting constituents, but it doesn't explicitly say when to use it or when to prefer an alternative. There are no stated exclusions or direct references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest NAV and metadata for one AMFI scheme code.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme_code | Yes | AMFI scheme code, e.g. 119551 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds the 'Latest' temporal context and the fact that both NAV and metadata are returned, but does not go beyond annotations significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the essential purpose with no wasted words. It is compact and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup, the description adequately conveys what the tool returns and when it applies. There is no output schema, but 'NAV and metadata' gives enough high-level return context for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including a type and example for scheme_code. The tool description only restates 'one AMFI scheme code', adding no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Latest NAV and metadata' for 'one AMFI scheme code', identifying the resource and the scope. It does not use an explicit verb, and it does not name sibling tools, but the phrase 'one scheme code' helps distinguish it from search and history siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have a specific AMFI scheme code and need its current NAV and metadata. It does not explicitly mention alternatives like mf_nav_history or mf_search_schemes, or provide exclusion criteria, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all ~14,000 Indian mutual fund schemes by name, AMC or category, from AMFI's daily industry NAV file. Returns scheme code, name, AMC, category, ISINs and latest NAV. Use the returned scheme_code with mf_nav_history. A scheme's NAV may be null when it did not report that day.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-100 | |
| query | Yes | Substring of scheme name, AMC or category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, openWorld, and idempotent. The description adds meaningful behavioral context beyond those hints: data comes from AMFI's daily NAV file, results may include null NAV when a scheme did not report that day, and the returned content includes ISINs and latest NAV. This helps the agent interpret the open-world, daily-updated nature of the data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences each earn their place: the first defines scope and source, the second lists returned fields and the downstream tool, and the third discloses the null-NAV edge case. Information is front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read-only search with no output schema, the description covers source, scale, searchable attributes, returned fields, downstream usage, and a data-quality caveat. Nothing critical is missing for an agent to call the tool correctly and handle results sensibly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description reinforces that 'query' matches name, AMC or category, matching the schema's own description, but it does not add new parameter-level details. The 'limit' parameter is already fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search all ~14,000 Indian mutual fund schemes'), defines the searchable dimensions (name, AMC or category), and names the data source (AMFI's daily industry NAV file). It clearly differentiates itself by listing the returned fields and routing the scheme_code to mf_nav_history, distinguishing it from siblings like mf_scheme or mf_nav_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage workflow: use it to discover schemes by name/AMC/category, then pass the returned scheme_code to mf_nav_history. It does not explicitly mention alternatives or negative cases ('do not use when...'), but the routing instruction and scope make the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily OHLCV series for one NSE symbol over a date range. Each day is a separate archive file, so the range is capped at 120 calendar days; for multi-year history use a pre-built warehouse instead. Non-trading days are absent from the series and counted in days_unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ISO end date YYYY-MM-DD, inclusive | |
| start | Yes | ISO start date YYYY-MM-DD, inclusive | |
| symbol | Yes | NSE ticker, e.g. RELIANCE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld. The description adds non-obvious behavior: per-day archive files explain the range cap, and non-trading days are absent but counted in days_unavailable. This is meaningful beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler; the core purpose, an important constraint, and a behavioral nuance are each addressed in one compact sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only historical data tool, it states what is returned (OHLCV series), the date range semantics, the cap, the alternative for longer ranges, and handling of non-trading days. No output schema exists, but the description covers the essential return concept well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear descriptions (ISO dates and NSE ticker). The description only restates the date-range idea and does not add parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific resource: 'Daily OHLCV series for one NSE symbol over a date range.' This clearly identifies what the tool retrieves and separates it from sibling nse_eod_quote, which implies a single quote rather than a multi-day series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit boundaries: a 120-calendar-day cap and a redirect to a pre-built warehouse for multi-year history. It does not explicitly contrast with sibling nse_eod_quote, so it misses full alternative routing, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End-of-day OHLCV for an NSE-listed stock, from NSE's official published bhavcopy archive. This is SETTLED END-OF-DAY data, never a live intraday price — do not present it as the current price. Omit trade_date for the most recent published trading day. Returns open/high/low/close, previous close, volume, turnover and trade count.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | NSE ticker, e.g. RELIANCE, TCS, INFY | |
| trade_date | No | ISO date YYYY-MM-DD. Omit for the latest trading day. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and open-world, and the description adds meaningful context beyond those: it emphasizes the data is SETTLED END-OF-DAY, warns against presenting it as the current price, and discloses the source as NSE's bhavcopy archive. It also lists the returned fields, which is valuable without an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences: purpose and source, a critical behavioral caveat, and usage plus return fields. Every sentence contributes meaning and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, read-only tool with no output schema, the description is complete: it names the data source, states the settled-data caveat, explains the default behavior for trade_date, and enumerates the returned metrics. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents symbol examples and the ISO date format for trade_date including the 'omit for latest' behavior. The description mostly restates the trade_date guidance, adding little semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns end-of-day OHLCV for an NSE-listed stock from the official bhavcopy archive, so its core purpose is unambiguous. However, it does not explicitly differentiate itself from the sibling nse_eod_history, leaving the single-day vs. multi-day distinction implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is settled end-of-day data, not a live intraday price, and trade_date can be omitted for the most recent trading day. It does not explicitly name alternatives like nse_eod_history for historical ranges, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Constituent stocks of an NSE index (e.g. 'NIFTY 50', 'NIFTY BANK'), from the CSV that NIFTY Indices publishes. Returns company name, industry, symbol, series and ISIN. CONSTITUENT WEIGHTS ARE NOT AVAILABLE — NSE publishes them only in factsheet PDFs and a paid product, so do not infer or estimate them.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Index name, e.g. 'NIFTY 50', 'NIFTY IT' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotent annotations, the description adds valuable behavioral context: the data source is a NIFTY Indices CSV, and critically, constituent weights are not available and must not be inferred or estimated. This is actionable and prevents a common misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the core functionality and returned fields first, then adds the critical weight-availability warning. Every sentence earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description is nearly complete: it names the output fields and the major constraint (no weights). The only notable gap is not pointing to list_nse_indices as the way to enumerate valid index names, though the examples and schema partially mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100%, with the schema already specifying 'Index name' and examples. The description contributes an additional example ('NIFTY BANK') and clarifies the NSE context, but it does not add substantial semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('constituent stocks of an NSE index') and the fields returned (company name, industry, symbol, series, ISIN). It lacks an explicit action verb like 'fetch' or 'list' and does not explicitly differentiate from sibling tools, so it is clear but not maximally distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need the constituent stocks of an NSE index. However, it provides no explicit when-not-to-use guidance and does not mention alternatives such as list_nse_indices for discovering available index names or nse_eod_quote/history for price data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a LOCAL SAMPLE of SEBI enforcement orders by text, entity or year. IMPORTANT: this corpus is a small sample (see corpus_size in the response), NOT SEBI's complete enforcement archive. If a search returns nothing, say that the sample contains no match — never conclude that SEBI has issued no order against the entity.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Filter by order year, e.g. 2026 | |
| limit | No | Max results, 1-100 | |
| query | No | Free text over title, entity, violation type | |
| entity | No | Filter by entity name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses the critical non-obvious behavior: the corpus is a sampled subset and the response contains a corpus_size field. It also warns against over-generalizing from empty results. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main purpose appears first, followed by the crucial sample caveat in an IMPORTANT callout. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with four optional parameters, no output schema, and no nested objects, the description provides the one essential contextual fact needed to avoid a serious error: the corpus is a local sample, not a complete archive. The agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for all four parameters. The description restates that search can be by text, entity, or year, but adds no new parameter semantics such as interaction rules, defaults, or precedence. The schema does the heavy lifting, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Search', and names the exact resource, 'a LOCAL SAMPLE of SEBI enforcement orders', along with the search dimensions (text, entity, year). The explicit 'LOCAL SAMPLE' framing and domain distinction from the NSE/MF sibling tools make the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit interpretive guidance: this is a small sample, not SEBI's complete archive, so empty results must be reported as 'no match in the sample' and never as evidence that SEBI issued no order. This is strong, actionable when-to-use and when-not-to-conclude guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0list_nse_indicesmf_nav_historymf_schememf_search_schemesnse_eod_historynse_eod_quotense_index_constituentssebi_search_ordersScored across 8 tools
Each tool targets a distinct resource and action: single-day NSE quote vs. history, index listing vs. constituents, mutual fund search vs. latest scheme data vs. historical NAV, and SEBI orders. The descriptions clearly separate even the closest pairs, so an agent should not confuse them.
All names are readable snake_case, but conventions are mixed: some use verb-first forms like list_nse_indices, mf_search_schemes, and sebi_search_orders, while others are noun-first like nse_eod_quote, nse_index_constituents, and mf_nav_history. The prefix placement is also inconsistent (nse_ vs. list_nse_).
Eight tools is well-scoped for a financial data server covering NSE equities, indices, mutual funds, and SEBI sample data. Each tool provides a meaningful capability with no obvious redundancy or padding.
The surface covers core EOD equity, index constituents, mutual fund NAV, and SEBI order search workflows, but there are notable gaps: no index quote/history tool, no way to search/list NSE symbols, and no mutual fund category-level or performance comparisons. SEBI search is intentionally limited to a sample, which is documented but still restricts coverage.
A Model Context Protocol server exposing real-time and historical Colombo Stock Exchange (CSE) data to AI agents and LLM applications. Provides quotes and OHLCV price history, full financial statements (income, balance sheet, cash flow), pre-computed technicals (moving averages, RS ratings, volume signals), macroeconomic indicators, corporate actions, and rule-based screening across CSE stocks and sector indices, everything needed to build CSE-aware trading assistants, research tools, and market-analysis agents. This is the official MCP server of www.ceyloncharts.com
MCP server for stocksense-ai documentation, generated by doc2mcp.
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.
MFAPI.in MCP — Indian mutual-fund NAV (net asset value) data.
