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., "@Indian Stock Exchange API2 MCP Server What are the latest upcoming IPOs and most active stocks on NSE?"
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.
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-indian_stock_exchange_api2）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: Tapetide MCP Server
这是一个使用 FastMCP 自动生成的 MCP 服务器，用于访问 Indian Stock Exchange Api2 API。
PyPI 包名: bach-indian_stock_exchange_api2
版本: 1.0.0
传输协议: stdio
pip install bach-indian_stock_exchange_api2pip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-indian_stock_exchange_api2 bach_indian_stock_exchange_api2
# 或指定版本
uvx --from bach-indian_stock_exchange_api2@latest bach_indian_stock_exchange_api2python server.py# 安装
pip install bach-indian_stock_exchange_api2
# 运行（命令名使用下划线）
bach_indian_stock_exchange_api2此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"indian_stock_exchange_api2": {
"command": "python",
"args": ["E:\path\to\indian_stock_exchange_api2\server.py"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}注意: 请将 E:\path\to\indian_stock_exchange_api2\server.py 替换为实际的服务器文件路径。
此服务器提供以下工具:
corporate_actionsGet Corporate Actions Data
端点: GET /corporate_actions
参数:
stock_name (string) 必需: Example value: infosys
historical_dataEndpoint: /historical_data - Method: GET - Query Parameters: - stock_name (required): string - period (optional): string, default is \
端点: GET /historical_data
参数:
stock_name (string) 必需: Example value: tcs
period (string): Example value:
filter (string): Example value:
mutual_fund_searchGET /mutual_fund_search Description: This endpoint allows you to search for mutual funds. Parameters: - query (string, required): The search term to query the mutual funds. Response: ```json [ { \端点: GET /mutual_fund_search
参数:
query (string) 必需: Example value: nippon
ipoGet latest upcoming, listed, active, closed IPO data.
端点: GET /ipo
nse_most_active/NSE_most_active Method: GET Description: Get the latest most active stocks in the National Stock Exchange (NSE) based on trading volume. Example Request: http GET /NSE_most_active Example Response: ```json [ { \端点: GET /NSE_most_active
stock_forecasts$237
端点: GET /stock_forecasts
参数:
stock_id (string) 必需: Example value: TCS
measure_code (string) 必需: Example value:
period_type (string) 必需: Example value:
data_type (string) 必需: Example value:
age (string) 必需: Example value:
historical_statsEndpoint: /historical_stats - Method: GET - Query Parameters: - stock_name (required): string - stats (required): string - Description: Retrieve historical statistics for a specific stock. - Example Request: http GET /historical_stats?stock_name=TATAMOTORS\u0026stats=quarter_results
端点: GET /historical_stats
参数:
stock_name (string) 必需: Example value: TCS
stats (string): Example value:
fetch_52_week_high_low_data$238
端点: GET /fetch_52_week_high_low_data
mutual_funds/mutual_funds Method: GET Description: Retrieve the latest data for mutual funds, including net asset value (NAV), returns, and other details. Example Request: http GET /mutual_funds Example Response: ```json { \端点: GET /mutual_funds
bse_most_active/BSE_most_active Method: GET Description: Get the latest most active stocks in the Bombay Stock Exchange (BSE) based on trading volume. Example Request: http GET /BSE_most_active Example Response: ```json [ { \端点: GET /BSE_most_active
commodity_futures_data_api$239
端点: GET /commodities
get_stock_data_by_name$23a
端点: GET /stock
参数:
name (string) 必需: Example value: tata steel
price_shockers/price_shockers Method: GET Description: Get data for stocks that have experienced significant price changes in a short period of time. Example Request: http GET /price_shockers Example Response: ```json [ { \端点: GET /price_shockers
industry_search$23b
端点: GET /industry_search
参数:
query (string) 必需: Example value: tata
analyst_recommendations$23c
端点: GET /stock_target_price
参数:
stock_id (string) 必需: Example value: TCS
get_trending_stocks$23d
端点: GET /trending
FastMCP: 快速、Pythonic 的 MCP 服务器框架
传输协议: stdio
HTTP 客户端: httpx
此服务器由 API-to-MCP 工具自动生成。
版本: 1.0.0
$23c
| Name | Required | Description | Default |
|---|---|---|---|
| stock_id | Yes | Example value: TCS |
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 of behavioral disclosure. '$23c' reveals nothing about side effects, return format, rate limits, or whether this is a read or write operation. The agent cannot determine what happens when this tool is invoked.
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?
While the description is short, it is not 'concise'—it is empty. Conciseness requires efficient communication of meaning. This description fails to communicate anything and therefore earns no credit for structure; every sentence must earn its place, and there are zero coherent sentences.
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 financial data tool with 15+ siblings and no annotations/output schema, the description should clarify the data source, recommendation types (buy/sell/hold), and timeframes. The content '$23c' represents a complete absence of necessary 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 description coverage is 100% (1 parameter with description field), establishing a baseline of 3. The description itself adds no parameter information, but the schema provides an example value 'TCS' which, combined with the parameter name 'stock_id', minimally clarifies the expected input format.
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 '$23c' is gibberish and conveys no information about what the tool does. While the tool name 'analyst_recommendations' suggests it retrieves financial analyst recommendations, the description itself is completely opaque and fails to specify the verb, resource, or scope.
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?
There is zero guidance on when to use this tool versus siblings like 'stock_forecasts' or 'get_stock_data_by_name'. The description provides no contextual boundaries or prerequisites for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
/BSE_most_active Method: GET Description: Get the latest most active stocks in the Bombay Stock Exchange (BSE) based on trading volume. Example Request: http GET /BSE_most_active Example Response: ```json [ { \| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It clarifies that 'most active' means based on 'trading volume,' but fails to mention timeframe (what constitutes 'latest'), rate limits, required authentication, or the structure/format of returned stock data. The truncated example response compounds this lack of 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 front-loaded with the core purpose, but includes unnecessarily verbose API documentation formatting (markdown headers, '**Endpoint:**', HTTP method syntax) that adds noise for an AI agent. The severely truncated example response ending with escaped quotes ('\"') creates visual clutter and incomplete 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?
Without an output schema or annotations, the description should fully explain return values, but the example response is cut off mid-JSON. It omits what fields are returned (symbol, price, volume, percentage change), how many stocks are included in the results, and the critical distinction from `nse_most_active` needed for appropriate tool selection.
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 contains zero parameters, which per evaluation rules establishes a baseline score of 4. No parameter semantic information is required or expected in the description.
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 'the latest most active stocks in the Bombay Stock Exchange (BSE) based on trading volume,' providing specific verb, resource, and sorting criteria. However, it fails to explicitly distinguish from the sibling tool `nse_most_active` (National Stock Exchange), which is a critical distinction given both exist on the same server.
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 no guidance on when to use this tool versus the sibling `nse_most_active` tool, nor any prerequisites or conditions. The description focuses exclusively on technical endpoint documentation rather than selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
$239
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. The string '$239' reveals nothing about read/write status, side effects, authentication requirements, or rate limits.
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?
While brief, the token '$239' contains zero actionable information and fails to earn its place. It is not appropriately sized or structured as a functional description.
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 financial data tool with numerous sibling market data endpoints, the description fails to explain what commodity futures data is returned, what timeframes are covered, or how to interpret the output.
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 contains zero parameters (properties is an empty object), establishing a baseline score of 4 per evaluation guidelines.
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 '$239' is completely opaque and fails to state what the tool does. It is neither a specific verb+resource combination nor does it distinguish from sibling market data tools like 'historical_data' or 'stock_forecasts'.
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 no guidance on when to use this tool versus the 13 sibling market data tools available. There are no 'when-to-use' or 'when-not-to-use' indicators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Corporate Actions Data
| Name | Required | Description | Default |
|---|---|---|---|
| stock_name | Yes | Example value: infosys |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet reveals nothing about the operation's safety profile, rate limits, data freshness, pagination behavior, or what specific corporate action types are returned.
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?
While brief at only four words, this represents under-specification rather than purposeful conciseness. No sentence earns its place because the content adds minimal value beyond the tool name itself.
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 financial data tool with many siblings, the description inadequately explains the scope of returned data or output format. The lack of output schema increases the burden on the description, which fails to compensate.
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 100% schema description coverage (the 'stock_name' parameter has a description with an example value), the baseline score is 3. The description adds no additional parameter semantics, but the schema adequately covers the single input field.
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 'Get Corporate Actions Data' essentially restates the tool name with a generic verb added, constituting a near-tautology. It fails to specify what corporate actions entail (dividends, splits, mergers, etc.) or distinguish this tool from siblings like 'historical_data' or 'get_stock_data_by_name'.
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?
No usage guidance is provided. The description contains no information about when to use this tool versus alternatives like 'historical_data', nor does it mention prerequisites or scoping limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
$238
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. '$238' reveals nothing about whether this reads from cache, requires API keys, returns formatted data, or has rate limits. It is effectively empty.
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?
While extremely brief (4 characters), '$238' is cryptic rather than concise. It is not 'front-loaded' with useful information—instead, it appears to be a placeholder, corrupted value, or meaningless string that wastes the single descriptive field.
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 complexity of financial data retrieval, the absence of an output schema, and lack of annotations, the description should explain return format, data sources, or ticker handling. '$238' provides none of this necessary 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 input schema has zero parameters and 100% description coverage. Per rubric guidelines, zero parameters establishes a baseline of 4. The description '$238' adds no explanatory value about why no inputs are needed (e.g., global context), but there are no parameters to document.
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 '$238' is completely opaque and fails to state what the tool does. It gives no indication that this tool fetches 52-week high/low stock data, forcing reliance solely on the tool name.
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?
No guidance provided on when to use this tool versus siblings like 'historical_data' or 'get_stock_data_by_name'. The description lacks any conditional logic or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
$23a
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Example value: tata steel |
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 of disclosing behavioral traits (side effects, rate limits, data freshness). The '$23a' placeholder reveals nothing about whether this is a read-only operation, if it requires API keys, or what volume of data is returned.
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?
While '$23a' is brief, it represents under-specification rather than effective conciseness. The description fails to front-load any meaningful information and does not earn its place as valid documentation.
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 complexity of stock data retrieval and lack of output schema, the description should explain what data points are returned (price, volume, P/E, etc.). The placeholder '$23a' provides no indication of the tool's scope or return values, making it completely inadequate.
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% description coverage (the 'name' parameter includes an example value 'tata steel'). With high schema coverage, the baseline score is 3 even though the description '$23a' adds no semantic value regarding the parameter.
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 '$23a' is meaningless placeholder text that fails to state what the tool does. It does not mention retrieving stock data, financial information, or any specific verb and resource combination. The name 'get_stock_data_by_name' implies the function, but the description itself provides zero informational value.
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?
There is no guidance on when to use this tool versus its 15 siblings (such as historical_data, analyst_recommendations, or price_shockers). The placeholder '$23a' offers no context about whether this returns real-time vs. delayed data, fundamental vs. technical data, or how it differs from other data retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
$23d
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. '$23d' reveals nothing about data sources, rate limits, caching behavior, or what defines a 'trending' stock. It fails to disclose any behavioral traits.
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?
While '$23d' is short, it is not 'concise' in the positive sense—it is meaningless placeholder text that wastes the agent's context window. It fails the 'every sentence should earn its place' test by providing negative information 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?
Despite having no input parameters (simple surface area), the tool lacks an output schema and has numerous siblings with overlapping domains (most_active, price_shockers). The description fails to explain the scope of data, time windows, or markets covered, leaving critical gaps.
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 contains zero parameters (empty object). According to the scoring rubric, 0 parameters establishes a baseline score of 4, as there are no parameters requiring semantic explanation beyond what the schema trivially 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 is literally '$23d', which appears to be a placeholder or corrupted variable reference. It contains no verb, no resource description, and does not explain that this tool retrieves trending stocks or what 'trending' means in this context.
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?
There is zero guidance on when to use this tool versus sibling alternatives like 'bse_most_active', 'nse_most_active', or 'price_shockers'. The string '$23d' provides no semantic content about usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Endpoint: /historical_data - Method: GET - Query Parameters: - stock_name (required): string - period (optional): string, default is \
| Name | Required | Description | Default |
|---|---|---|---|
| stock_name | Yes | Example value: tcs | |
| period | No | Example value: | |
| filter | No | Example value: |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full disclosure burden. It only reveals the HTTP method (GET), implying a read operation, but fails to specify the data format returned, what constitutes a valid period string, rate limits, or error behavior. The default value description is truncated ('default is \"'), leaving critical behavioral context missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The formatting is garbled (markdown bullets merged into a single line) and the text appears truncated mid-value. While brief, the structure is poor for an AI reader, mixing endpoint syntax with parameter documentation without clear intent hierarchy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking output schema and annotations, a data retrieval tool needs description of return values (OHLCV? adjusted prices? splits/dividends?). The description omits what 'historical data' encompasses, pagination behavior, and time range limits, leaving critical gaps for invocation planning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description merely lists parameters already documented in the schema without adding semantic depth (e.g., explaining period formats like '1Y' vs '5Y', or filter syntax). The schema examples are empty strings for optional parameters, which the description doesn't compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides technical endpoint details (GET /historical_data) and parameter listings but fails to state what business function it performs (e.g., 'retrieves historical price data'). It restates implementation metadata rather than describing the tool's purpose or distinguishing it from siblings like historical_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives (e.g., get_stock_data_by_name for current prices, historical_stats for aggregates). No mention of prerequisites, data availability constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Endpoint: /historical_stats - Method: GET - Query Parameters: - stock_name (required): string - stats (required): string - Description: Retrieve historical statistics for a specific stock. - Example Request: http GET /historical_stats?stock_name=TATAMOTORS\u0026stats=quarter_results
| Name | Required | Description | Default |
|---|---|---|---|
| stock_name | Yes | Example value: TCS | |
| stats | No | Example value: |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses HTTP method (GET) which implies read-only behavior, but lacks critical behavioral context given no annotations exist. Does not specify what statistics types are available, response format, encoding, or pagination behavior. Full burden of transparency falls on description due to missing 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?
Uses structured markdown with endpoint details and code block example, which is scannable but front-loads HTTP implementation details over semantic meaning. The backslash-escaped ampersand in example URL is noisy. Could be more concise while retaining the useful example request.
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?
Incomplete for a data retrieval tool with no output schema. Missing: valid values for 'stats' parameter, distinction from 'historical_data', response structure documentation, and error conditions. The parameter contradiction further reduces 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?
Major contradiction: description marks 'stats' as required, but input schema only lists 'stock_name' in required array. While description provides helpful example 'quarter_results', it fails to explain valid enum values for 'stats' parameter or semantic meaning beyond 'statistics'. Schema descriptions are minimal ('Example value: TCS'), requiring description to compensate more than it does.
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?
States clear verb-resource combination ('Retrieve historical statistics for a specific stock'), but fails to differentiate from sibling tool 'historical_data'. The distinction between 'statistics' and 'data' is implied but not explained, leaving ambiguity when to choose this over the sibling.
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 an example request showing 'quarter_results' as a stats value, but offers no explicit guidance on when to use this tool versus 'historical_data' or other data retrieval siblings. No prerequisites, rate limits, or filtering guidance mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
$23b
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Example value: tata |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet '$23b' reveals nothing about whether this is read-only, what data sources it queries, rate limits, or whether results are cached or real-time.
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?
While extremely brief, '$23b' represents under-specification rather than purposeful conciseness. It contains no actionable information and fails to front-load any meaningful guidance about the tool's function.
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 lack of annotations, absence of output schema, and the presence of numerous financial search siblings, the tool requires descriptive context to distinguish its purpose. The description fails completely to explain what constitutes an 'industry' in this context or what data is returned.
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 100% schema description coverage (the 'query' parameter includes an example value 'tata'), the baseline score is 3. The description adds no semantic value regarding what the query should contain (e.g., industry names vs. codes), but the schema sufficiently documents the input format.
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 '$23b' is not descriptive text at all; it appears to be a data value or placeholder that erroneously replaced the actual description. It fails to state what the tool searches for, what 'industry' refers to (sectors, classifications, etc.), or what the return data represents.
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?
There is zero guidance on when to use this tool versus siblings like 'mutual_fund_search' or 'get_stock_data_by_name'. The description provides no context about the search scope or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest upcoming, listed, active, closed IPO data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full behavioral burden. While 'Get' implies read-only, it doesn't confirm safety, disclose rate limits, caching behavior, or what structure/format the IPO data returns (critical given no output schema exists).
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?
Single efficient sentence front-loaded with action and scope. No wasted 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?
Lists data categories retrieved but omits return format/structure since no output schema exists. For a read-only data tool with no inputs, adequately describes content but not container (JSON structure, pagination, etc.).
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?
Zero parameters per schema, triggering baseline score of 4. Description correctly implies no filtering capabilities by listing all IPO categories covered.
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?
Clear verb 'Get' and specific resource 'IPO data' with explicit categorization (upcoming, listed, active, closed). Differentiates from siblings like get_stock_data_by_name or historical_data by focusing exclusively on IPO lifecycle stages.
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?
No explicit guidance on when to use versus other data retrieval tools, nor prerequisites for accessing IPO data. Lacks 'when-not-to-use' or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
/mutual_funds Method: GET Description: Retrieve the latest data for mutual funds, including net asset value (NAV), returns, and other details. Example Request: http GET /mutual_funds Example Response: ```json { \| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. While it notes the GET method (implying read-only), it omits critical details: dataset scope (all funds or top N?), pagination behavior, rate limits, and authentication requirements. The truncated example response ('{ \"') further reduces 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?
Description suffers from formatting clutter (markdown headers '###', '**Endpoint:**') that adds noise for AI consumption. The embedded example response is truncated mid-JSON, indicating poor structuring. Content is not front-loaded; HTTP method details appear before the semantic description.
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?
Without an output schema, the description should explain return values, but the example response is cut off. The zero-parameter schema suggests this returns a large dataset, yet no pagination or filtering guidance is provided. Sibling tool relationships remain unexplained.
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?
Input schema has zero parameters. Per evaluation rules, zero parameters warrants a baseline score of 4. The description does not need to compensate for missing parameter documentation.
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?
States clear verb ('Retrieve') and resource ('mutual funds'), specifying data types returned (NAV, returns). However, it fails to differentiate from the 'mutual_fund_search' sibling tool, leaving ambiguity about when to use list vs 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?
Contains no guidance on when to use this tool versus alternatives like 'mutual_fund_search' or 'historical_data'. No prerequisites, filtering capabilities, or usage constraints are mentioned despite the zero-parameter schema implying a broad data dump.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET /mutual_fund_search Description: This endpoint allows you to search for mutual funds. Parameters: - query (string, required): The search term to query the mutual funds. Response: ```json [ { \| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Example value: nippon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the HTTP method (GET) implying read-only behavior, but provides no other behavioral details. With no annotations provided, the description fails to cover: authentication requirements, rate limits, pagination behavior, or what occurs when no results match the query.
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?
Uses markdown header syntax ('### Mutual Fund Search') and API documentation boilerplate ('Endpoint', 'Parameters') that adds unnecessary noise. The response section is abruptly truncated ('[ { \'), indicating poor editing and structural bloat.
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 single-parameter search tool, the description covers the input parameter but lacks critical context: no output schema explanation (despite mentioning Response), no differentiation from similar siblings, and no behavioral constraints. Incomplete for practical agent usage.
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?
Description states the query is 'The search term to query the mutual funds,' which adds semantic intent. However, with 100% schema description coverage already providing an example value ('nippon'), the description adds minimal value beyond the schema itself, warranting the baseline score.
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?
States the tool searches for mutual funds, which is clear. However, it fails to differentiate from the sibling tool 'mutual_funds' (also present in the server), leaving ambiguity about which to use for specific retrieval scenarios.
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 no guidance on when to use this tool versus alternatives. The distinction from the 'mutual_funds' sibling is not explained, and there are no conditions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
/NSE_most_active Method: GET Description: Get the latest most active stocks in the National Stock Exchange (NSE) based on trading volume. Example Request: http GET /NSE_most_active Example Response: ```json [ { \| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It mentions the GET method and 'latest' data (implying real-time/recent), but lacks critical behavioral details: rate limits, what constitutes 'most active' (top N count?), pagination behavior, market hours relevance, or safety guarantees. The truncated example response is cut off mid-JSON, reducing utility.
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?
Markdown formatting with endpoint/method headers adds structural clarity but also verbosity. The core description is one clear sentence. However, the included example response is truncated/malformed (ending with escaped quotes), which wastes space and creates visual noise without adding 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?
Adequate for a zero-parameter retrieval tool. It identifies the exchange (NSE) and metric (volume), but given the lack of output schema, the truncated example JSON could have provided critical field documentation if complete. Missing operational context like data freshness guarantees or rate limiting.
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?
Input schema has zero parameters (100% coverage trivially satisfied). The description correctly implies this is a parameterless fetch operation requiring no filters, meeting the baseline expectation for zero-parameter tools.
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 (Get), resource (most active stocks), and scope (NSE based on trading volume). It implicitly distinguishes from sibling 'bse_most_active' by specifying the National Stock Exchange, though it doesn't explicitly differentiate from 'get_trending_stocks' or 'price_shockers'.
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?
No explicit guidance on when to use this tool versus siblings like 'bse_most_active' or 'get_trending_stocks'. While the NSE naming provides implicit context, there are no stated prerequisites or exclusion criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
/price_shockers Method: GET Description: Get data for stocks that have experienced significant price changes in a short period of time. Example Request: http GET /price_shockers Example Response: ```json [ { \| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. It redundantly includes HTTP metadata (endpoint path, GET method) instead of describing actual behavior like data freshness, rate limits, what constitutes a 'shocker,' or the response structure. The example response is truncated and incomplete.
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 poorly structured, beginning with markdown headers (###) and including redundant HTTP implementation details (Endpoint, Method) that waste tokens. The actual semantic content is a single sentence. The inclusion of incomplete code examples that truncate mid-string further degrades structural quality.
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?
With no output schema provided, the description must compensate by describing what data is returned, but it only describes the input filter (price shockers). It fails to indicate what fields are returned (price change percentage, volume spike, timestamp, etc.), leaving the agent blind to the tool's actual utility and return format.
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 contains zero parameters. According to calibration guidelines, this establishes a baseline score of 4. The description correctly avoids inventing parameter documentation where none exist.
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 data for stocks with 'significant price changes in a short period of time,' providing a specific verb (Get data), resource (stocks), and filter criteria (significant price changes). However, it does not explicitly differentiate from similar volatility-focused siblings like 'get_trending_stocks' or 'fetch_52_week_high_low_data.'
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?
No guidance is provided on when to use this tool versus siblings. There is no mention of prerequisites, no explicit 'use this instead of X' directives, and no indication of what constitutes 'significant' price changes or what timeframes are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
$237
| Name | Required | Description | Default |
|---|---|---|---|
| stock_id | Yes | Example value: TCS | |
| measure_code | Yes | Example value: | |
| period_type | Yes | Example value: | |
| data_type | Yes | Example value: | |
| age | Yes | Example value: |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure burden. '$237' reveals nothing about safety profile (read-only vs destructive), side effects, rate limits, or return format. The agent cannot determine if this retrieves cached data or triggers a new forecast calculation.
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?
While physically brief (4 characters), this represents under-specification rather than efficient conciseness. The single 'sentence' fails to earn its place by communicating any actionable information. Front-loading is moot when the content is opaque.
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?
Completely inadequate for a 5-parameter financial forecasting tool with no output schema and no annotations. The description '$237' provides none of the necessary context for an agent to understand forecast retrieval semantics, data types, or expected behavior.
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%, establishing baseline 3 per evaluation rules. However, the '$237' description adds zero semantic value about the 5 parameters (stock_id, measure_code, period_type, data_type, age). The schema descriptions are themselves minimal ('Example value: TCS' or empty strings), but the description does not compensate by explaining what 'measure_code' or 'period_type' mean.
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 '$237' is meaningless as a functional description. It contains no verb, no indication of what resource is accessed, and does not distinguish this forecasting tool from sibling tools like 'analyst_recommendations' or 'historical_data'.
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?
Absolutely no guidance provided on when to use this tool versus alternatives, prerequisite conditions, or expected workflows. The string '$237' offers no contextual clues for agent selection.
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. Dates show when Glama detected each change.
v1.0.0analyst_recommendationsbse_most_activecommodity_futures_data_apicorporate_actionsfetch_52_week_high_low_dataget_stock_data_by_nameget_trending_stockshistorical_datahistorical_statsindustry_searchipomutual_fund_searchmutual_fundsnse_most_activeprice_shockersstock_forecastsScored across 16 tools
Most tools have distinct purposes (e.g., bse_most_active vs. nse_most_active, historical_data vs. historical_stats), but there is some overlap between get_stock_data_by_name and historical_data, and between mutual_funds and mutual_fund_search. The descriptions help clarify differences, but an agent might occasionally misselect between closely related tools.
Naming is inconsistent with mixed conventions: some use snake_case (e.g., analyst_recommendations, get_stock_data_by_name), others use camelCase (e.g., fetch_52_week_high_low_data), and some are abbreviated (e.g., ipo). There's no uniform verb_noun pattern, making the set less predictable and harder to navigate.
With 16 tools, the count is slightly high but reasonable for a stock exchange API covering multiple domains like stocks, commodities, mutual funds, and IPOs. It's borderline heavy but justifiable given the broad scope, though some consolidation might improve coherence.
The toolset covers key areas like stock data, historical info, and market activity, but there are notable gaps: no update or delete operations (expected for an API), and limited coverage for corporate actions or commodity futures beyond basic fetching. It supports core queries but lacks full lifecycle management for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Indian NSE/BSE research data and mechanically-computed ratios; read-only market tools.
Market data, financial statements, valuation, research, and news for investment workflows.
Analyze stocks with summaries, price targets, and analyst recommendations. Track SEC filings, divi…
Live market data, financial analysis, and portfolio research tools across 10,000+ tickers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/bach-indian_stock_exchange_api2'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
