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., "@moneycontrol-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.
An MCP server that exposes Moneycontrol market data as tools an AI agent can call: symbol search, live equity quotes, fundamentals & ratios, index levels, FII/DII institutional activity (cash market + F&O), market news, and technical pivot levels.
Moneycontrol has no official public API. This server talks to the same public endpoints the Moneycontrol website and app use (
priceapi.moneycontrol.com, the autosuggest service, the FII/DII page's embedded data, and RSS feeds). It is intended for personal/informational use; respect Moneycontrol's terms of service and avoid hammering the endpoints. All data is read-only.
Tool | What it does |
| Search a stock or index by name → resolve its |
| Live equity quote: price, change, OHLC, 52-week range, volume, market cap. |
| Valuation ratios (P/E standalone & consolidated, industry P/E, P/B), book value, cash EPS, face value, dividend yield, sector, and 1w–5y returns. |
| Current level/movement for an index (Nifty 50, Sensex, Nifty Bank, sectoral indices, …). |
| FII & DII net activity in ₹ crore — cash market headline plus F&O segments, by day. |
| Current news headlines for a topic/stock ( |
| Pivot points and support/resistance levels (daily/weekly/monthly). |
| Historical OHLCV bars for an NSE stock — daily/weekly/monthly or intraday (1m–1h). |
Every tool accepts response_format: "markdown" (default, human-readable) or "json"
(structured, for programmatic use).
Related MCP server: india-stock-mcp
Requires Python 3.10+. Uses uv (or plain pip).
uv venv --python 3.11
uv pip install -e .# stdio transport (for local MCP clients)
uv run moneycontrol-mcp
# or
uv run python -m moneycontrol_mcpAdd to your MCP client config (e.g. claude_desktop_config.json), using absolute paths:
{
"mcpServers": {
"moneycontrol": {
"command": "uv",
"args": ["--directory", "/ABSOLUTE/PATH/TO/Money control mcp", "run", "moneycontrol-mcp"]
}
}
}In Claude Code:
claude mcp add moneycontrol -- uv --directory "/ABSOLUTE/PATH/TO/Money control mcp" run moneycontrol-mcpuv run python scripts/smoke_test.pyThis calls every tool against the live endpoints and prints the results.
moneycontrol_search(query="HDFC Bank") → sc_id: "HDF01"
moneycontrol_get_quote(symbol="HDF01") → live price
moneycontrol_get_fundamentals(symbol="HDF01") → P/E, P/B, dividend yield
moneycontrol_fii_dii(days=5, segment="cash") → were foreigners buying this week?
(The quote/fundamentals/technicals tools also accept a plain company name and will
auto-resolve it via search, but passing the sc_id is faster and unambiguous.)
Cash market FII/DII figures (fiiCM/diiCM) are the headline numbers; F&O
segments are also exposed via segment="fno" or "all".
Index codes for the most common indices are built in; any other index name is resolved at runtime via Moneycontrol search.
Historical data (moneycontrol_get_history) is for NSE equities via the
techCharts feed; index history and BSE-only scrips are not currently supported.
Commodity/forex quotes are not included: Moneycontrol's public price feed requires contract/expiry-specific codes for those and is not reliably accessible.
Top gainers/losers, options chain, and corporate actions are not included:
Moneycontrol does not expose clean public JSON endpoints for these. If you need
them, the NSE-backed tools in sibling MCP servers (e.g. finstack's
nse_top_movers / nse_options_chain / nse_corporate_actions, or dhan)
cover that ground.
Data reflects whatever Moneycontrol publishes (often delayed during market hours; provisional FII/DII data updates after market close).
Get FII (foreign) and DII (domestic) institutional net activity, in INR crore.
The cash market is the headline figure most analysts watch: positive FII cash = foreign buying. F&O segments (index/stock futures & options) are also available. A positive number = net buying; negative = net selling.
Args: params (FiiDiiInput): - days (int): Recent trading days to return (1-60, default 10). - segment (str): 'cash' (default), 'fno', or 'all'. - response_format (ResponseFormat): 'markdown' or 'json'.
Returns: str: A list of daily rows (most recent first). Each row (JSON mode): { "date": str, "fii_cash": float, "dii_cash": float, "net_cash": float, # when segment is 'fno' or 'all': "fii_index_fut": float, "fii_index_opt": float, "fii_stock_fut": float, "fii_stock_opt": float, "nifty_close": str, "nifty_change_pct": str } All cash/F&O figures are net values in INR crore. Returns "Error: ..." on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by explaining the meaning of positive and negative values, the structure of the return data, segments, and error handling. No contradictions.
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 well-structured, starting with a clear purpose, then elaborating on segments, parameter details, and return format. Every sentence adds necessary information, and there is no redundancy or 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 the comprehensive input schema and the detailed description of the return format (including JSON structure with fields and explanations), the tool is fully documented. It covers purpose, parameters, behavior, segments, units, and error handling.
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 detailed descriptions for all parameters (days, segment, response_format), covering 100% of parameter semantics. The description repeats these (e.g., 'days (int): Recent trading days to return (1-60, default 10)') with minor additions like 'The cash market is the headline figure.' The added value is minimal beyond the schema, 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 tool 'Get FII (foreign) and DII (domestic) institutional net activity, in INR crore.' This is a specific verb-resource combination. While it does not explicitly differentiate from siblings, the focus on institutional activity and the mention of cash and F&O segments make its purpose unique among the listed 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 provides context (e.g., 'The cash market is the headline figure most analysts watch') but does not explicitly state when to use this tool versus alternatives or when not to use it. There is no mention of sibling tools or conditions for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get valuation ratios, per-share metrics, sector and trailing returns for a stock.
Covers P/E (standalone & consolidated), industry P/E, P/B, book value, cash EPS, face value, dividend yield, market cap, sector classification, and price returns over 1w / 1m / 3m / 1y / YTD plus 5-year CAGR.
Args: params (FundamentalsInput): - symbol (str): sc_id (preferred) or company name. - exchange (str): 'nse' (default) or 'bse'. - response_format (ResponseFormat): 'markdown' or 'json'.
Returns: str: Fundamentals with this shape (JSON mode): { "name": str, "sc_id": str, "sector": str, "sub_sector": str, "pe": str, "pe_consolidated": str, "industry_pe": str, "pb": str, "book_value": str, "cash_eps": str, "face_value": str, "dividend_yield": str, "market_cap_cr": str, "returns": {"1w": str, "1m": str, "3m": str, "1y": str, "ytd": str, "cagr_5y": str} } Returns "Error: ..." on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds error behavior ('Returns Error: ... on failure') and a detailed output shape, which provides context beyond 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 well-structured with clear sections: purpose, coverage, Args, Returns. It is concise without superfluous text, front-loading the main 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?
Given the presence of annotations, output shape in description, and sibling context, the description is fairly complete. It covers input, output format, error cases, and parameter details. Minor gap: could explicitly contrast with siblings, but not critical.
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?
Although schema description coverage is 0% by metric, the description includes an 'Args' section that explains the purpose of each parameter (symbol, exchange, response_format) and provides default values and constraints, adding 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 states the tool gets valuation ratios, per-share metrics, sector and trailing returns for a stock. It specifies 'fundamentals' which distinguishes it from sibling tools like moneycontrol_get_history or moneycontrol_get_technicals.
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 stock fundamentals but does not explicitly state when to use this tool versus other sibling tools like moneycontrol_get_quote or moneycontrol_get_technicals. No 'when not to use' or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical OHLCV price bars for an NSE stock (daily/weekly/monthly or intraday).
Args: params (HistoryInput): - symbol (str): NSE trading symbol (e.g. 'RELIANCE', 'HDFCBANK') or company name. - interval (str): 1m, 5m, 15m, 30m, 1h, daily (default), weekly, monthly. - count (int): Number of most-recent bars (1-500, default 30). - response_format (ResponseFormat): 'markdown' or 'json'.
Returns: str: Bars ordered oldest → newest. Each bar (JSON mode): {"time": str, "open": float, "high": float, "low": float, "close": float, "volume": float} JSON mode wraps them as {"symbol", "ticker", "interval", "count", "bars": [...]}. Returns "Error: ..." on failure (e.g. no data at that resolution).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent behavior. The description adds details on error messages ('Error: ...' on failure), ordering (oldest to newest), and output structure, providing useful behavioral context beyond 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 structured with Args and Returns sections, making it easy to scan. It is slightly verbose but every sentence adds context. No redundancy with the schema.
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 in the provided context, the description compensates by specifying the return format and example. Error handling is mentioned. For a data retrieval tool, this is sufficiently 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?
The input schema already describes each parameter (symbol, interval, count, response_format) with details. The description adds narrative examples and clarifies default values, but the schema already covers the essentials, so the description adds moderate value.
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 historical OHLCV price bars for NSE stocks, specifying intervals and output format. It distinguishes from sibling tools by focusing on price history versus news, fundamentals, 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?
The description does not explicitly state when to use this tool over alternatives or provide exclusion criteria. However, the tool's name and purpose imply it is for historical price data, which differentiates it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current level and movement for a market index.
Built-in fast-path names: Nifty 50, Sensex, Nifty Bank, Nifty IT, Nifty Auto, Nifty Pharma, Nifty FMCG, Nifty Metal, Nifty Midcap 100, Nifty Smallcap 100, Nifty 500. Other index names are resolved automatically via Moneycontrol search.
Args: params (IndexInput): - index (str): Index name or raw pricefeed code. - response_format (ResponseFormat): 'markdown' or 'json'.
Returns: str: Index data with this shape (JSON mode): { "name": str, "level": str, "change": str, "percent_change": str, "open": str, "high": str, "low": str, "prev_close": str, "advances": str, "declines": str, "year_high": str, "year_low": str, "ytd_percent": str } Returns "Error: ..." on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return shape in JSON mode and error behavior ('Returns "Error: ..." on failure'). Annotations already declare readOnlyHint and idempotentHint; the description adds context about index resolution and output details, adding value beyond 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 structured with paragraphs for purpose, fast-path names, args, and returns. It is somewhat verbose but clear and front-loaded. Some repetition of schema details could be trimmed.
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?
The tool is simple (get index level) and the description covers usage, output shape, and error handling. Annotations provide safety guarantees. The description is mostly complete, though it could note that the output may vary for unrecognized indices.
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 already contains descriptions for both parameters (index and response_format). The description restates these with similar wording, adding little new meaning. Given schema coverage is effectively high, a baseline score of 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 tool retrieves current level and movement for a market index, listing built-in fast-path names. It is specific but does not explicitly differentiate from sibling tools like moneycontrol_get_quote or moneycontrol_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?
The description provides context on when to use the tool by listing built-in index names and mentioning automatic resolution via Moneycontrol search. It does not explicitly state when not to use or provide alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current Moneycontrol news headlines for a topic, stock, or category.
Pass a query for targeted news (a company name gives stock-specific news; a
topic like 'rbi policy' or 'crude oil' gives that theme). With no query, a
category supplies a sensible default search: markets, latest, business,
economy, results, stocks, ipo, mutual-funds.
Args: params (NewsInput): - query (Optional[str]): Topic/stock/keyword. Overrides category. - category (str): Default category when query is omitted ('markets'). - limit (int): Max headlines (1-50, default 15). - response_format (ResponseFormat): 'markdown' or 'json'.
Returns: str: A list of current articles. Each (JSON mode): {"title": str, "link": str} Returns "No news found..." when nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds context on return format (markdown or json), the structure of returned articles, and the empty response message, enhancing transparency without contradiction.
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 concise (three paragraphs) with clear sections (Args and Returns). It is front-loaded with the main purpose and uses bullet-like structure to list parameters, making it easy to scan.
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 four parameters, detailed schema descriptions, and an output schema, the description covers all essential aspects: query vs category behavior, limit range, response format, and return format. It is complete for an agent to use 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 description explains the meaning and interaction of 'query' and 'category', and mentions 'limit' and 'response_format'. Although the input schema provides detailed descriptions for nested parameters, the tool description adds practical usage context and the relationship between parameters.
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 'Get current Moneycontrol news headlines for a topic, stock, or category.' It uses a specific verb and resource, and the examples distinguish it from sibling tools like moneycontrol_get_quote or moneycontrol_search.
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 use 'query' vs 'category' and the default category. It provides clear internal usage context but does not explicitly tell when to avoid this tool in favor of siblings, though the purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a live equity quote: price, change, OHLC, 52-week range, volume, market cap.
Args: params (QuoteInput): - symbol (str): sc_id (preferred) or company name. - exchange (str): 'nse' (default) or 'bse'. - response_format (ResponseFormat): 'markdown' or 'json'.
Returns: str: Quote data with this shape (JSON mode): { "name": str, "symbol": str, "exchange": str, "sc_id": str, "price": str, "change": str, "percent_change": str, "prev_close": str, "open": str, "high": str, "volume": str, "week52_high": str, "week52_low": str, "market_cap_cr": str, "market_state": str, "last_updated": str } Returns "Error: ..." on failure (e.g. unknown symbol).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the error handling behavior ('Returns Error: ...') and the return shape, but this is minimal additional behavioral context beyond what annotations provide.
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 well-structured with sections for Args and Returns, using bullet points. It front-loads the purpose sentence. While it is somewhat lengthy, it earns its space by providing essential details without 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's simplicity and the presence of a detailed output schema in the description, all necessary information is covered: purpose, parameters, error handling, and return format. No gaps remain.
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 0% per context, but the description compensates by explaining each parameter: symbol (sc_id or name), exchange (nse/bse), response_format (markdown/json). It adds nuances like 'preferred' for sc_id, which is helpful beyond the schema's basic types.
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 explicitly states 'Get a live equity quote' and lists the data points (price, change, OHLC, etc.). It clearly distinguishes from sibling tools like moneycontrol_get_fundamentals and moneycontrol_get_history, which serve different purposes.
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 clear instructions on how to use the parameters (symbol as sc_id or name, exchange defaults to nse, response_format options). However, it does not explicitly state when to use this tool versus alternatives, though the context of siblings makes it somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pivot points and support/resistance levels for a stock.
Args: params (TechnicalsInput): - symbol (str): sc_id (preferred) or company name. - exchange (str): 'nse' (default) or 'bse'. - period (str): 'D' (daily, default), 'W', or 'M'. - response_format (ResponseFormat): 'markdown' or 'json'.
Returns:
str: OHLC for the period plus pivot tables. JSON mode returns the raw
Moneycontrol structure including pivotLevels (Classic, Fibonacci, etc.).
Returns "Error: ..." on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context: returns OHLC and pivot tables, supports two output formats ('markdown' or 'json'), and returns error messages ('Error: ...'). It does not contradict annotations. It discloses important behavior beyond what annotations provide, but could include more about potential rate limits or auth.
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, uses bullet points for parameters, and clearly separates Args and Returns. Every sentence adds value without redundancy. It is front-loaded with the core 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?
Given that an output schema exists (context signal indicates true) and annotations cover safety, the description provides sufficient context: it specifies the return type (str), describes the content (OHLC and pivot tables), and explains error handling. No critical information 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?
Despite the context signal indicating 0% schema description coverage, the description thoroughly explains all parameters: symbol (sc_id or company name), exchange (nse default or bse), period (D, W, M), and response_format (markdown or json). It adds value by clarifying that sc_id is preferred and noting defaults. This fully compensates for the lack of 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 'Get pivot points and support/resistance levels for a stock.' This is a specific verb ('Get') and resource ('pivot points and support/resistance levels'), and it distinguishes the tool from siblings like moneycontrol_get_fundamentals (which retrieves financial data) and moneycontrol_get_quote (which gets current price).
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 explicit guidance on the input parameters (symbol, exchange, period, response_format) and return format. It implies when to use this tool (for technical analysis data) but does not explicitly mention when not to use it or compare with alternatives. However, it covers the context well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Moneycontrol for a stock or index and resolve its identifiers.
Use this FIRST to obtain a stock's sc_id (needed by moneycontrol_get_quote,
moneycontrol_get_fundamentals, moneycontrol_get_technicals) or to discover an
index name accepted by moneycontrol_get_index.
Args: params (SearchInput): - query (str): Name to search. - kind (str): 'stock' (default) or 'index'. - limit (int): Max results (1-25, default 10). - response_format (ResponseFormat): 'markdown' or 'json'.
Returns: str: Matches. Each record has: { "sc_id": str, # Moneycontrol id, e.g. "RI" — pass to quote/fundamentals "name": str, # Display name "symbol": str, # Trading symbol, e.g. "RELIANCE" "isin": str, # ISIN if available "bse_code": str, # BSE numeric code if available "sector": str, "link": str # Moneycontrol page URL } Returns "No matches..." when nothing is found.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds value by explaining the return format, the meaning of sc_id, and the behavior on no matches. No contradictions.
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 well-structured with Args and Returns sections and is front-loaded with the core purpose. Every sentence adds value, though it is slightly longer than strictly necessary.
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?
The description is complete for a search tool: it explains inputs, outputs (including example return), and how the result is used downstream. The presence of an output schema (not shown) further reduces the need for description, but the description already covers 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?
Despite 0% schema coverage, the description thoroughly documents all four parameters in the Args section, adding context like default values (kind defaults to 'stock', limit defaults to 10) and the purpose of sc_id for sibling tools. This more than compensates for schema gaps.
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 searches Moneycontrol for a stock or index and resolves identifiers, specifically mentioning it's the first step to obtain sc_id for other tools. It distinguishes from siblings by positioning itself as the initial lookup tool.
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 says 'Use this FIRST' and explains why (to obtain sc_id or index name). It does not mention when not to use it, but the context is clear and sufficient for typical use cases.
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.0moneycontrol_fii_diimoneycontrol_get_fundamentalsmoneycontrol_get_historymoneycontrol_get_indexmoneycontrol_get_newsmoneycontrol_get_quotemoneycontrol_get_technicalsmoneycontrol_searchScored across 8 tools
Each tool has a clearly distinct purpose: FII/DII data, fundamentals, history, index, news, quote, technicals, and search. No two tools overlap in functionality; an agent can easily select the right one.
Most tools follow the pattern 'moneycontrol_get_<noun>' (e.g., get_fundamentals, get_quote), but moneycontrol_fii_dii omits 'get_' and moneycontrol_search uses 'search' instead of 'get_search'. The deviation is minor and still readable.
With 8 tools, the set is well-scoped for a financial data server. Each tool covers a distinct aspect of market data (quotes, history, indices, fundamentals, technicals, news, institutional flows, and search), fitting the domain without being bloated.
The tool surface covers essential financial data operations: live quotes, historical prices, indices, fundamentals, technicals, news, and institutional activity. Minor gaps exist (e.g., no options/futures data, corporate actions), but core workflows are supported.
MCP server for stocksense-ai documentation, generated by doc2mcp.
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
MCP server exposing the Backtest360 engine API as tools for AI agents.
The Octagon MCP server provides specialized AI-powered financial research and analysis by integrating with the Octagon Market Intelligence API. It enables users to analyze public market data (SEC filings, earnings transcripts, financial metrics, and stock data for 8000+ companies), private market data (3M+ companies, 500k+ funding rounds, 2M+ M&A/IPO transactions), and conduct deep research including web scraping capabilities. The server also features autonomous research agents that search hundreds of sources and return fully cited reports in approximately one minute.
