Click on "Install 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., "@india-stock-mcp Get quote for Reliance Industries"
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.
MCP server for Indian stock market data — NSE/BSE quotes, historical prices, fundamentals, mutual fund NAV, indices, corporate actions, F&O option chains, IPOs, and portfolio analysis.
Works with any MCP client: Claude Desktop, Claude Code, Cursor, etc. No API keys, no auth, all free data sources.
Tool | What it does |
| Live price, volume, 52-week range for NSE/BSE stocks and indices |
| OHLCV history — daily / weekly / monthly |
| Find stock symbols by company name |
| P/E, EPS, ROE, margins, debt, growth rates |
| 2–5 stocks side by side |
| Any NSE index (P/E, P/B, advances/declines) + SENSEX |
| Is the market open? Session info per segment |
| Top NIFTY 50 movers ranked by % change |
| Dividends, splits, bonuses — per stock or market-wide |
| F&O chain around ATM: LTP, OI, OI change, IV, volume |
| Current / upcoming / recently listed IPOs |
| Search 15,000+ Indian mutual fund schemes |
| NAV history for a scheme |
| Fund house, category, current NAV |
| 2–4 funds: NAV + % return over any period |
| Holdings → current value, P&L, allocation breakdown |
Related MCP server: Indian Market MCP
Node.js 22+
No clone, no build:
Claude Code
claude mcp add india-stock -- npx -y india-stock-mcpClaude Desktop — add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):
{
"mcpServers": {
"india-stock": {
"command": "npx",
"args": ["-y", "india-stock-mcp"]
}
}
}git clone https://github.com/Akhilgovind02/india-stock-mcp.git
cd india-stock-mcp
npm install
npm run build
claude mcp add india-stock -- node /absolute/path/to/india-stock-mcp/dist/index.jsRestart Claude Desktop fully, then look for the tools icon in a new chat.
"Quote for RELIANCE and how far is it from its 52-week high?"
"Compare HDFC Bank vs ICICI Bank vs SBI fundamentals"
"Top 5 NIFTY 50 gainers today"
"NIFTY option chain — where's the max open interest?"
"Compare Parag Parikh Flexi Cap vs Quant Small Cap over 3 years"
"Analyze my portfolio: 10 RELIANCE @ 1200, 5 TCS @ 3000"
npm run dev # run from TypeScript directly
npx tsx scripts/test-mcp.ts # end-to-end test of all 16 tools (live data)
npx tsx scripts/test-edge.ts # 24 edge-case assertions
npm run build # compile to dist/Real output from npx tsx scripts/test-mcp.ts (live data, market hours, June 2026 — trimmed):
TOOLS: get_quote, get_historical, search_symbol, search_funds, get_fund_nav,
get_fundamentals, compare_stocks, get_index, get_market_status, get_gainers_losers,
get_corporate_actions, get_options_chain, get_ipo_list, get_fund_details,
compare_funds, portfolio_summary
PASS get_quote: {"source":"Yahoo Finance","symbol":"RELIANCE.NS","name":"RELIANCE
INDUSTRIES LTD","price":1266,"changePct":0.23,"volume":6107188,...}
PASS get_index: {"source":"NSE","index":"NIFTY BANK","last":55915,"percentChange":1.34,
"yearHigh":61764.85,"pe":...}
PASS get_market_status: [{"market":"Capital Market","marketStatus":"Open",...}]
PASS get_gainers_losers: {"type":"gainers","universe":"NIFTY 50","data":[{"symbol":
"SHRIRAMFIN","changePct":3.17,...}]}
PASS get_corporate_actions: {"symbol":"RELIANCE","actions":[{"subject":"Dividend -
Rs 5.5 Per Share","exDate":"14-Aug-2025",...}]}
PASS get_options_chain: {"symbol":"NIFTY","underlyingValue":23331,"atmStrike":23350,
"availableExpiries":["16-Jun-2026",...],"data":[{"strikePrice":...,"CE":{"lastPrice":
130.95,"openInterest":144769,"impliedVolatility":12.26},...}]}
PASS get_ipo_list: {"type":"current","ipos":[{"companyName":"Utkal Speciality
Industries India Limited","status":"Active",...}]}
PASS compare_funds: {"comparison":[{"name":"Parag Parikh Flexi Cap Fund - Direct
Plan - Growth","latestNAV":88.484,...}]}
PASS portfolio_summary: {"summary":{"totalInvested":41000,"totalCurrentValue":38663,
"totalPnL":-2337,"totalPnLPct":-5.7,...}}
... all 16 tools PASSSource | Used for | Notes |
Yahoo Finance ( | Quotes, history, fundamentals, search | Primary source, may be delayed a few minutes |
NSE India ( | Market status, indices, corporate actions, IPOs, option chains | Some NSE endpoints (quote, autocomplete) are no longer publicly accessible — the server falls back to Yahoo automatically |
Mutual fund NAV and search | Free, occasionally flaky — requests retry once | |
Fund ratings / expense ratio | Often unreachable; falls back to mfapi.in |
get_gainers_losers ranks a built-in NIFTY 50 constituent list (verified June 2026). NSE reconstitutes the index ~2×/year — update NIFTY50_SYMBOLS in src/index.ts when that happens.
Quotes may be delayed (Yahoo free feed); not suitable for live trading decisions.
NSE may rate-limit or block heavy usage.
Data comes from free public sources and may be delayed, incomplete, or wrong. This is not financial advice and not a substitute for a licensed broker or advisor. Do your own research before trading or investing.
Compare 2–4 mutual funds side by side: latest NAV and % return over the chosen period.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Comparison period in days (NAV entries are trading days) | |
| scheme_codes | Yes | Array of AMFI scheme codes e.g. ["122639", "120503"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the range of funds and metrics, but does not mention data freshness, authentication needs, or read-only nature. It provides adequate basic transparency.
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, front-loaded sentence that efficiently communicates the tool's purpose. Every word is valuable.
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?
Given the tool has no output schema, the description indicates what is returned (latest NAV and % return). It covers the main behaviors but could mention that data is provided for each fund in the side-by-side comparison.
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 is 100% with clear descriptions for both parameters. The description adds context by connecting the parameters to the comparison output, but does not significantly exceed the schema's information.
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 verb 'compare' and the resource 'mutual funds', and specifies the metrics (latest NAV and % return) and the allowed number of funds (2–4). It effectively differentiates from sibling tools like 'compare_stocks'.
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 usage for comparing mutual funds by name and the context of sibling tools (e.g., 'compare_stocks') makes the domain clear. However, it lacks explicit guidance on when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2–5 stocks side by side: price, P/E, EPS, market cap, margins, growth rates.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | Array of NSE symbols to compare e.g. ["HDFCBANK", "ICICIBANK", "SBIN"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only lists metrics but does not disclose whether data is real-time, delayed, requires authentication, or behavior on invalid symbols. Minimal behavioral disclosure.
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?
One sentence with no wasted words; it is efficient and directly states the tool's purpose and scope.
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 comparison tool with one well-documented parameter and no output schema, the description is minimally complete. However, it could mention the return format or data source for better completeness.
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% for the single parameter, with a clear example and constraints. The tool description adds no new information beyond what the schema provides, so baseline 3 is appropriate.
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 verb 'Compare' and the resource 'stocks', and lists specific metrics (price, P/E, etc.). It distinguishes from sibling 'compare_funds' by specifying stocks vs funds.
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 usage for side-by-side stock comparison with 2-5 symbols, but does not explicitly state when to use this tool versus alternatives like get_fundamentals or get_quote. No exclusions or typical use cases mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dividends, stock splits, bonus issues, and rights issues. Pass a symbol for one stock, or omit it for recent market-wide corporate actions.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date YYYY-MM-DD (default: today) | |
| from | No | Start date YYYY-MM-DD (default: 1 year ago) | |
| symbol | No | NSE symbol e.g. RELIANCE, INFY. Omit for market-wide list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It lists the types of corporate actions but does not disclose additional behavioral traits like rate limits, authentication needs, or response format. Adequate but not extensive.
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?
Two sentences: first defines the action types, second explains parameter usage. No fluff, front-loaded with key information.
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 tool with 3 optional parameters and no output schema, the description covers the essential functionality and parameter usage. It is sufficient for an agent to understand when and how to use it.
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 is 100% with descriptions for each parameter. The description adds extra context for the 'symbol' parameter, including examples and behavior when omitted. For 'to' and 'from', it confirms default values already in 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 specifies the tool retrieves dividends, stock splits, bonus issues, and rights issues. It distinguishes from siblings like get_historical or get_quote by focusing on corporate actions.
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 explains when to pass a symbol (for one stock) and when to omit (for market-wide). It does not explicitly state when not to use this tool, but context from sibling tools implies alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fundamental financial data: P/E ratio, EPS, ROE, revenue, profit margins, debt, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | NSE stock symbol e.g. HDFCBANK, INFY, WIPRO |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It indicates read-only behavior (get) and lists typical financial metrics, but does not disclose caching, authentication needs, or any potential side effects.
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 sentence that efficiently conveys the tool's output. It is concise but could be slightly improved with a clearer layout (e.g., bullet points for listed metrics).
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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate. It explains what data is returned but lacks details on format, limitations, or usage context.
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 schema already provides a clear description for the single 'symbol' parameter (including examples). The tool description adds no extra semantic value beyond this; baseline 3 is appropriate due to high schema coverage.
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 retrieves fundamental financial data and lists specific metrics (P/E ratio, EPS, etc.). This creates a distinct purpose from siblings like get_quote or get_historical.
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 (when needing fundamental data) but does not explicitly exclude alternatives or provide guidance on when not to use it. No mention of prerequisites or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get mutual fund details: fund house, category, current NAV. Includes Morningstar rating, expense ratio, and AUM when the rich data source is available.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme_code | Yes | AMFI scheme code from search_funds e.g. '122639' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes that rich data (Morningstar rating, expense ratio, AUM) depends on data source availability. However, it does not disclose read-only nature or other behavioral aspects.
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?
Two concise sentences covering purpose and available data without unnecessary words. Front-loaded with main action.
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?
Description is adequate for a tool with one parameter and no output schema. It explains what data is returned and when rich data is available. Could mention default behavior when source unavailable, but overall complete.
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?
Only one parameter (scheme_code) with schema description already explaining it. The description adds a hint to use search_funds for the code, but no additional meaning beyond 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 it retrieves mutual fund details including fund house, category, NAV, and additional data when available. It distinguishes from siblings like get_fund_nav which only returns NAV.
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 use when details beyond NAV are needed, but does not explicitly state when to use vs alternatives like get_fund_nav or search_funds. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top gainers or losers among NIFTY 50 stocks, ranked by % change (live Yahoo quotes).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Whether to get top gainers or top losers | |
| count | No | How many stocks to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (live Yahoo quotes) and ranking basis (% change), but lacks details on update frequency, reliability, rate limits, or authentication needs. No annotations provided, so description carries full burden.
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?
One clear, front-loaded sentence with no redundant information. Every word adds value.
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?
Missing output format description (e.g., list of stocks with symbol, % change), especially since no output schema exists. Also lacks mention that data is live and changes per call.
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 descriptions already fully cover both parameters (type enum, count numeric). The description adds 'ranked by % change' but this is about output, not parameter semantics.
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?
Clearly states the tool retrieves top gainers or losers from NIFTY 50 stocks ranked by % change using live Yahoo quotes. This specific verb-resource combination distinguishes it from sibling tools like get_quote or compare_stocks.
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?
Implied usage when needing top movers, but no explicit when-to-use or when-not-to-use guidance. Does not contrast with similar tools like get_quote that could provide individual stock data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OHLCV historical price data for a stock. Returns date, open, high, low, close, volume.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date in YYYY-MM-DD format | |
| from | Yes | Start date in YYYY-MM-DD format | |
| symbol | Yes | NSE stock symbol e.g. RELIANCE, TCS | |
| interval | No | Data interval: 1d (daily), 1wk (weekly), 1mo (monthly) | 1d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the returned fields (date, OHLCV) but omits behavioral traits like read-only nature, data source (NSE via symbol param), rate limits, or potential error conditions. It is adequate but minimal.
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?
Two sentences with no unnecessary words. Front-loaded with purpose, then output fields. Highly efficient.
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?
Given no output schema, the description mentions return fields but not structure (array order, pagination). It covers the essential output adequately for a simple data retrieval tool, but could be more complete.
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 is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it only lists output fields. Parameter descriptions in schema are sufficient, but the description does not provide contextual guidance on usage.
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's purpose: 'Get OHLCV historical price data for a stock.' It specifies the resource (OHLCV historical price data) and target (stock), distinguishing it from sibling tools like get_quote (current price) or get_corporate_actions.
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 usage for historical data but offers no explicit guidance on when to use this tool versus alternatives like get_quote. No when-not-to-use or sibling comparisons are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live data for a market index: price, change, P/E, P/B, year high/low, advances/declines. Available: NIFTY 50, NIFTY BANK, NIFTY IT, NIFTY MIDCAP 100, NIFTY SMALLCAP 100, NIFTY AUTO, NIFTY PHARMA, SENSEX, and all other NSE indices.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Index name e.g. 'NIFTY 50', 'NIFTY BANK', 'NIFTY IT', 'SENSEX', 'NIFTY MIDCAP 100' |
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 the tool returns 'live data', implying a read-only operation with no side effects. While it does not contradict any annotations, it lacks details on rate limits, authorization, or data freshness.
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 efficient: two sentences front-load the data points and then list available indices. Every sentence adds essential information with no redundancy.
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?
Given the tool has only one parameter and no output schema, the description fully covers the necessary context: what data is returned and which indices are supported. It is complete for a straightforward lookup 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 coverage is 100% for the single parameter 'index', which includes a description with examples. The description adds value by listing all available index values, extending beyond the schema's example list.
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 that the tool gets live data for a market index and enumerates specific data points (price, change, P/E, etc.), making its purpose unambiguous. It distinguishes itself from sibling tools like get_quote or get_market_status by focusing on index-specific metrics.
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 comprehensive list of available indices (NIFTY 50, SENSEX, etc.), which helps the agent know when to use this tool. However, it does not explicitly state when not to use it or suggest alternative tools for related but different queries (e.g., individual stock quotes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of current, upcoming, or recently listed (past 3 months) IPOs on NSE.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | 'current' = open for subscription, 'upcoming' = announced, 'past' = listed in last 3 months | current |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the time range (past 3 months) but omits critical details such as default parameter behavior, pagination, rate limits, or data freshness. The schema notes a default of 'current', but the description does not reiterate this.
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 sentence that front-loads the core purpose. Every word contributes to understanding, with no redundancy or unnecessary detail.
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?
Given the tool's simplicity (one parameter, no output schema), the description is adequate for selection. However, it lacks details on the output format or contents (e.g., fields like company name, price), leaving the agent uncertain about what the result list includes.
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?
With schema description coverage at 100%, the schema already explains the parameter fully. The tool description does not add further semantic value beyond what is in the schema, meeting the baseline expectation without enhancement.
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 a list of IPOs on NSE, differentiating three categories (current, upcoming, past). The verb 'Get' and resource 'list of IPOs' are specific, and no sibling tool overlaps, making 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 explicitly indicates the tool is for obtaining IPO lists with time-based filtering. While it does not mention when not to use it or alternatives, the context is clear, and sibling tools do not cover IPOs, so no exclusions are necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if NSE market is currently open or closed, and get trading session info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as authentication requirements, rate limits, return format, or what happens when the market is closed. The description carries the full burden but only gives a high-level action.
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, concise sentence (14 words) that front-loads the key purpose. No unnecessary words.
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?
Given zero parameters and no output schema, the description covers the basic function. It could be more explicit about what 'trading session info' includes, but it is adequate for a simple check 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?
There are no parameters, and schema coverage is 100%. With zero parameters, baseline is 4; the description adds no extra meaning but doesn't need to.
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 checks whether the NSE market is open or closed and provides trading session info. It uses a specific verb ('Check') and resource ('NSE market') and naturally distinguishes from siblings like get_quote or get_historical.
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 usage for market status checks but does not explicitly state when to use it versus alternatives or provide conditions when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get F&O options chain for a stock or index: calls and puts around the ATM strike with last price, OI, OI change, IV, and volume. Works for NIFTY, BANKNIFTY, and F&O stocks like RELIANCE.
| Name | Required | Description | Default |
|---|---|---|---|
| expiry | No | Optional expiry in DD-Mon-YYYY format e.g. '16-Jun-2026'. Default: nearest expiry. | |
| symbol | Yes | NSE F&O symbol e.g. NIFTY, BANKNIFTY, RELIANCE, TCS | |
| strike_range | No | Optional +/- range in points around ATM strike to include |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes output fields but does not mention read-only nature, authentication requirements, or error cases when symbol is not F&O. Adequate but not thorough.
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?
Two sentences, efficient and front-loaded. No redundant information. Every word serves a purpose.
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?
No output schema, but description lists key returned fields (last price, OI, OI change, IV, volume). For a tool with 3 parameters and clear purpose, this is sufficient context.
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 is 100%, but description adds value: gives date format example for expiry and explains default behavior, and clarifies what strike_range does. This goes beyond schema descriptions.
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?
Description states verb (Get), specific resource (F&O options chain for a stock or index), and what it returns (calls/puts, specific fields). Clearly distinguishes from sibling tools which are for funds, fundamentals, quotes, etc.
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?
Explicitly says which symbols it works for (NIFTY, BANKNIFTY, F&O stocks like RELIANCE), implying scope. Does not explicitly state when not to use it, but context with siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live price, volume, 52-week range, and basic stats for an NSE/BSE stock. Examples: RELIANCE, TCS, HDFCBANK, NIFTY 50 (index), ^NSEI (Nifty index code).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | NSE stock symbol (e.g. RELIANCE, TCS, HDFCBANK) or index name (NIFTY 50, NIFTY BANK). Do NOT append .NS — it is added automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions automatic .NS suffix but does not disclose rate limits, error handling, or whether data is truly live versus cached. Some behavior is implicit but not comprehensive.
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?
Two sentences that front-load the tool's purpose and provide immediate examples. No fluff or repetition.
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?
Given the single parameter and lack of output schema, the description adequately explains inputs and expected data (price, volume, range, stats). Missing details on output format or error cases, but sufficient for basic use.
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 is 100% with a clear description for the symbol parameter. The description adds value by providing examples and noting automatic .NS appending, which goes 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?
Clearly states it retrieves live price, volume, 52-week range, and basic stats for NSE/BSE stocks or indices. The examples clarify what symbols to use, distinguishing it from sibling tools like compare_stocks or get_fundamentals.
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?
Provides examples but no explicit guidance on when to use this tool versus alternatives like compare_stocks or get_fundamentals. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a stock portfolio. Pass holdings with buy price and quantity, get current value, P&L, allocation breakdown, and gain/loss per holding. Max 20 holdings.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | Array of stock holdings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the outputs and inputs sufficiently for a read-only analysis tool. No annotations exist, so description carries burden; it does not mention auth needs, rate limits, or side effects, but given the nature of the tool, it is adequately transparent.
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?
Two sentences: first states purpose, second adds details and constraint. Every sentence is necessary and no fluff.
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?
Given no output schema and relatively simple input, the description fully explains what the tool does and provides a constraint. It covers inputs, outputs, and limits, making it complete for an AI to select and invoke 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?
Only one parameter (holdings) with 100% schema coverage. Description echoes the schema by mentioning 'holdings with buy price and quantity' but adds no further semantic detail beyond what is 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?
Clearly states it analyzes a stock portfolio with specific inputs (holdings, buy price, quantity) and outputs (current value, P&L, allocation, gain/loss per holding). Distinguishes from sibling tools like get_quote or compare_stocks.
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?
Describes when to use (analyze a portfolio) and includes a constraint (max 20 holdings). Does not explicitly mention when not to use or suggest alternatives, but the use case is clear and distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Indian mutual funds by name. Returns scheme codes and names for use with other fund tools.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Fund name or partial name e.g. 'HDFC Top', 'SBI Small Cap', 'Mirae Emerging', 'ELSS' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear full behavioral transparency. It discloses the tool's read-only search nature and return type, but lacks details on matching behavior (e.g., partial, fuzzy), pagination, result limits, or performance. It is adequate but minimal.
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?
Two concise sentences front-load the purpose and return value. No unnecessary words. Every sentence adds value.
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 search tool with one parameter and no output schema, the description adequately states purpose, input, and output (scheme codes and names). It could mention result count or behavior for invalid input, but is not incomplete.
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 is 100% with examples in the parameter description. The tool description adds a set of concrete examples ('HDFC Top', 'SBI Small Cap', etc.), providing additional clarity beyond the schema alone.
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 searches 'Indian mutual funds by name' and returns 'scheme codes and names', distinguishing it from siblings like search_symbol (stocks) and get_fund_details (specific fund). The verb 'Search' and resource are explicit.
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 usage for finding fund codes, but does not give explicit when-to-use or when-not-to-use instructions relative to siblings like search_symbol or get_fund_details. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a stock symbol by company name. Returns matching symbols with exchange info.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or partial name e.g. 'HDFC Bank', 'Tata Consul', 'Wipro' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only mentions what is returned and not limitations like case sensitivity, partial matching behavior, rate limits, or error conditions.
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?
Two sentences, no redundant words, front-loaded with the main action. Efficient and clear.
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 search tool, the description is adequate but could be more complete about what 'exchange info' entails. No output schema to supplement.
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 is 100% and the schema description already provides examples. The tool description adds no additional semantics beyond what the schema offers.
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 action ('Search for a stock symbol by company name') and what is returned ('matching symbols with exchange info'). It distinguishes from sibling tools like search_funds which search for funds.
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?
Usage context is implied (search when you have a company name), but there is no explicit guidance on when not to use it or alternatives for other scenarios (e.g., searching by symbol). Sibling tool names provide some context but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct domain or action: compare functions for stocks vs funds are separate; get_* tools for different data types (fundamentals, historical, quote, etc.); search tools for symbols and funds; portfolio summary is unique. No overlap.
Most tools follow a verb_noun pattern (get_, compare_, search_) in lowercase snake_case. 'portfolio_summary' is the exception as it starts with a noun, but it remains descriptive and fits the overall style. The inconsistency is minor.
With 16 tools covering stocks, mutual funds, indices, IPOs, market status, options, and portfolio analysis, the count is slightly high but well-justified for the breadth. It feels comprehensive without being excessive.
The tool set covers core data retrieval and analysis for stocks and mutual funds, including fundamentals, historical prices, comparisons, and portfolio summary. Missing areas like technical analysis or trading are likely out of scope. Minor gaps exist (e.g., no direct tool for stock screener), but overall it's thorough.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stock analysis MCP: 38 indicators, 7 optimizers, 8 backtests, US + India sectors.
Indian NSE/BSE research data and mechanically-computed ratios; read-only market tools.
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.
MCP server for stocksense-ai documentation, generated by doc2mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Akhilgovind02/india-stock-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
