nse-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation4/5
Each tool targets a distinct data type (quotes, history, option chains, indices, etc.). A few pairs like stock_quote vs stock_quote_fno or index_history vs index_pe_history might initially seem similar, but descriptions clarify the difference clearly.
Naming Consistency4/5
Most tools follow a snake_case 'resource_qualifier' pattern (e.g., stock_history, index_option_chain). Some variability exists: live_index vs index_list, pre_open_market, and option_chain_contract_info reverse the word order, but overall naming is predictable.
Tool Count4/5
24 tools is on the heavier side but covers a wide range of NSE data: equities, indices, F&O, options, currency, corporate actions, and market stats. Each tool serves a distinct purpose, so the count seems justified for the server's broad scope.
Completeness4/5
The toolset covers most core workflows: live quotes, historical data, option chains, market status, and corporate announcements. Minor gaps include currency spot quotes and more detailed corporate action data, but these aren't essential for typical NSE data needs.
Average 2.7/5 across 24 of 24 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as return format, data source, rate limits, or side effects. The sole phrase 'Option chain for an index' provides no information beyond the tool's name, so the description carries no transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It omits all useful information and is merely a noun phrase, failing to provide a functional description that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and zero parameter documentation, the description is completely inadequate for a tool with 2 parameters. The agent has no basis for understanding inputs, outputs, or behavior, making the description contextually incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention either parameter ('expiry' or 'symbol'). Without any explanation of what these parameters represent or how they affect results, the agent cannot infer their meaning beyond the raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase, 'Option chain for an index,' which essentially restates the tool name 'index_option_chain' without any action verb. It does not distinguish the tool from siblings like equities_option_chain or currency_option_chain, as it lacks specific scope or purpose details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, leaving the agent unable to determine the appropriate situation compared to sibling tools such as option_chain_contract_info or index_pe_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 it discloses nothing. It does not state whether the tool is read-only, what data it returns (e.g., deal records, timestamps, prices), or any limitations. For an agent considering invoking this tool, the behavior is entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single fragment 'NSE block deal session data' does not provide enough structure or information to be useful. It does not earn its place because it conveys no actionable content beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is the only source of context. It fails to explain what 'block deal session data' means, whether it is historical or real-time, or what the returned structure looks like. An agent cannot determine if this tool suits its task based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description adds no parameter-specific meaning, but none is needed because the input schema is empty. There is nothing about parameters that an agent needs to understand for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'NSE block deal session data' is a noun phrase that merely restates the tool name with 'NSE' prefixed. It lacks a verb indicating the action (e.g., retrieves, lists), making it essentially a tautology. It provides no differentiation from sibling tools like stock_quote or market_turnover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention any use case, prerequisites, or context in which block deal session data would be relevant. There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states a static fact about current securities and does not explain return format, real-time vs. delayed data, sorting, or any other behavior. This is insufficient for an agent to understand side effects or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified; it reads as a fragment rather than an informative sentence. Concise writing should preserve essential content, but here brevity sacrifices clarity and leaves the purpose ambiguous. This aligns with the low example where under-specification is not counted as good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an empty input schema, the description is the only source of context. It is too minimal to understand what the tool returns or how it behaves. For a simple tool this might be marginally acceptable, but the absence of any verb or output description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers all arguments (vacuously 100% coverage). The description adds no parameter meaning, but with no parameters, there is nothing to explain. The baseline of 4 is appropriate since no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('Securities currently in the F&O segment') with no verb, so it doesn't clearly state an action like 'list' or 'get'. It vaguely indicates the resource but fails to specify the operation, and it does not differentiate from sibling tools that also relate to F&O securities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no context, and no exclusions. The description provides no usage scenario or comparison to sibling tools such as stock_quote_fno or option_chain_contract_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states the resource name and does not disclose any behavioral traits: whether it's a read operation, what kind of data is returned, formatting, or any side effects. This is no more informative than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It lacks an action verb and important context, so it is not effectively front-loaded. The brevity is not a positive trait when it omits essential meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description should at least say 'returns all NSE indices' to be complete. Instead it is an incomplete noun phrase, leaving the agent unsure of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty schema). Per the baseline for 0 params, a score of 4 is appropriate; the description doesn't need to add parameter details, and it doesn't mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'All NSE indices.' restates the tool name without an action verb, so it doesn't clearly state what the tool does (e.g., list, fetch). It offers some scope (NSE) but is essentially tautological and does not differentiate from sibling tools like index_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of use cases, exclusions, or context for when this tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose return format, authentication needs, or side effects. The bare noun phrase 'Registrar details for a symbol' carries almost no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the brevity sacrifices essential information. It is under-specification rather than a concise, informative summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what registrar details include, any constraints, or the return structure. It provides none of this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a required symbol string with 0% description coverage. The description only indicates that registrar details are for that symbol, adding minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns registrar details for a symbol, which is a specific resource. It is clear about the purpose but does not explicitly differentiate from siblings such as symbol_meta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The description neither mentions exclusions nor suggests this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It only says 'Metadata for an NSE symbol,' which is a static definition and gives no information about side effects, authorization requirements, return format, or error behavior. This is severely inadequate for a tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of fluff, but it is under-specified to the point of being a noun phrase rather than a functional description. It is not well-structured for an agent to parse actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. For a metadata tool, the agent would need to know what fields are returned, whether the metadata is real-time or static, and any other behavioral context. The current description leaves the tool's behavior almost entirely undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'symbol' with zero description coverage. The tool description does not clarify the expected symbol format (e.g., 'RELIANCE' vs 'NSE:RELIANCE') or any constraints. The parameter name is self-explanatory but the description adds no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides 'Metadata for an NSE symbol,' which identifies the resource and type of information. However, it lacks a verb (e.g., 'get' or 'retrieve') and does not specify what metadata is included, making it only slightly more informative than the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as stock_quote or trade_info. There is no mention of prerequisites, typical use cases, or exclusions, so the agent cannot determine appropriate invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool returns an option chain for an equity, but does not mention data freshness, response structure, whether historical queries are supported, or any special permissions or restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than appropriately concise. It does not earn its place because it conveys minimal information beyond what the tool name already suggests.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and parameter descriptions, this tool needs more contextual detail. The description does not explain what an option chain includes, how expiry is used, or when to select this over the many related sibling tools, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for the 'symbol' or 'expiry' parameters. The term 'option chain' implies symbol is an underlying, but expiry is completely unexplained, leaving the agent without necessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as an option chain and scopes it to equities, which distinguishes it from sibling tools like index_option_chain and currency_option_chain. However, it lacks an explicit verb such as 'retrieve' or 'get', making it more of a label than a clear directive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. Sibling tools for index and currency option chains exist, but the description does not provide any distinguishing usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only says what the tool returns, not whether the data is live or static, what fields are included, or how invalid symbols are handled. It adds no context beyond the core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short fragment, which is efficient but not a complete sentence. It omits necessary context and reads more like a title than a functional description, though it is not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is not complete enough for an agent to understand the full behavior. It does not specify the return structure, potential errors, or whether the output is a simple list of index names or includes additional metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'symbol', but the description does not explain it at all. With 0% schema description coverage, the description fails to add meaning about the expected format, type, or examples, leaving the agent to guess what a valid 'symbol' looks like.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Indices that a stock belongs to' clearly identifies the resource (indices) and scope (for a given stock), effectively distinguishing it from siblings like 'all_indices' or 'live_index'. However, it lacks an explicit verb such as 'list' or 'get', so it reads more like a definition than an action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or other tools like 'all_indices' that might be confused with it. The description simply states the output concept without contextualizing when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to provide safety or behavioral context, and the description only says 'Live quote' without disclosing data freshness, response format, limitations, or any other behavioral traits. It adds little beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no wasted words. It is appropriately sized for a simple tool, though it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and lack of annotations, the description is incomplete: it omits usage context, output expectations, and relation to sibling tools. It is barely adequate for the simplest invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'symbol', with a default of 'NIFTY 50' and zero description coverage. The description does not mention or explain this parameter, providing no added meaning beyond the schema's basic property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides a 'Live quote' for an 'index', which is a specific verb and resource. This distinguishes it from stock quote tools and historical index tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus sibling tools like stock_quote or index_history. Usage is only implied by the tool name and generic description, offering no exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read operation, what output to expect, how defaults like segment='equities' behave, or any limitations such as date range constraints. The description is a static phrase with no behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is easy to read and front-loaded with the main subject. It uses minimal words, but it is under-specified rather than overly verbose. The structure is fine, though the content is too lean to earn a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four optional parameters, no annotations, and no output schema, the description is insufficient for an agent to effectively invoke the tool. It does not explain return structure, parameter constraints, or when this tool is the right choice among many siblings. It barely meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions segment, date range, and symbol as filter dimensions but does not explain their formats, valid values, or optionality. With 0% schema description coverage, the burden is on the description, and it fails to provide meaning beyond parameter names. For example, the date format for to_date/from_date is unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (corporate announcements) and filter scope (segment, date range, symbol), which distinguishes it from sibling tools like stock_quote or chart_data. However, it lacks an explicit verb like 'get' or 'list,' so it is a noun phrase rather than a complete action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention related tools like symbol_meta or stock_history, nor any prerequisites, exclusions, or use cases. The description is purely a resource description with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'intraday chart data' without explaining the time range, resolution, return format, or any limitations. The agent cannot anticipate what data will be returned or how to interpret it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff or repetition. It is front-loaded with the key concept 'intraday chart data' and is appropriately sized for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and relies on the description to explain return values and behavior. A one-sentence description is insufficient for a chart-data tool, as the agent does not know the data structure (e.g., OHLCV, timestamps) or how it differs from stock_history. Context from sibling tools is not enough to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one 'symbol' string parameter with zero description coverage. The tool description adds no meaning beyond the parameter name, failing to clarify acceptable values, format, or examples. This leaves the agent guessing what 'symbol' should look like.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Intraday chart data for a symbol' clearly identifies the resource (intraday chart data) and the scope (for a symbol). It distinguishes from sibling tools like stock_history (historical) and stock_quote (current quote) by specifying 'intraday', though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as stock_history or index_history. Sibling tool names suggest overlap, but the description does not mention any exclusions or alternative scenarios, leaving the agent to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only notes date format (YYYY-MM-DD) and that the data is 'records', but doesn't specify the structure of records, pagination, data units, or whether the data is adjusted. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core purpose. However, it is under-specified and omits critical details, making it more of a placeholder than a useful description. It doesn't waste words, but it also doesn't provide enough value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description provides almost no context on return values, parameter semantics, or usage constraints. It is minimal and leaves the agent with insufficient information to invoke the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate by explaining the parameters. It only states the date format and doesn't define the 'name' parameter (index identifier) or the semantics of date range (inclusive/exclusive). This minimal information doesn't help the agent construct valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides historical OHLC data for an index, with a specific resource (index) and scope (historical OHLC). It distinguishes from sibling tools like stock_history by specifying 'index'. However, the verb is implicit rather than explicit ('get'), and it doesn't explicitly name alternative tools, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving historical index OHLC data, but it doesn't provide explicit guidance on when to use this tool versus alternatives such as live_index or chart_data. No exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Pre-open market data for the given index key' without detailing what data is returned, whether it is real-time, any auth requirements, rate limits, or other side effects. The description is too thin to inform the agent about behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is structurally concise. However, it is under-specified rather than efficiently informative, omitting details that would help in tool selection and invocation. It earns its place but could be more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, no parameter schema descriptions, and no annotations, the description alone must make the tool fully understandable. It fails to explain what 'pre-open market data' consists of, which index keys are valid, or what the response looks like. This is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes a single parameter 'key' with no description, and the description refers to it as an 'index key', adding some semantic meaning beyond the bare property name. However, it does not enumerate accepted values, format, or relationship to the default 'NIFTY', so the compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool provides pre-open market data for an index key, which clearly identifies both the resource ('pre-open market data') and the parameter ('index key'). It is distinguishable from siblings like live_index or index_history due to the explicit 'pre-open' qualifier, though it lacks an explicit action verb like 'get' or 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as live_index, market_status, or all_indices. It does not mention any context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only mentions 'as records' and date format. It does not state read-only nature, pagination, output ordering, or error conditions, which is insufficient for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short sentence with no redundancy. Every word earns its place, and 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description is far too brief. It does not provide enough context about return structure, parameter constraints, or behavioral details to be complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only adds meaning for dates (YYYY-MM-DD) and implies the symbol context. It does not explain the 'series' parameter or the semantics of the date range, leaving gaps for 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides historical OHLCV data for a stock, which is specific and distinguishes it from index history or current quotes. It lacks an explicit verb like 'retrieve' but the noun phrase is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like stock_quote or chart_data. It does not mention any exclusions or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns available expiries and strikes, which implies a read-only lookup, but it does not mention return format, ordering, or any other behavioral aspects like authentication 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the essential information and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description is too sparse. It does not explain the output structure, usage context, or how this tool differs from the many option chain siblings. An agent would struggle to know when to select this tool and what to expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It defines the 'symbol' parameter as an 'option chain symbol,' which adds meaning beyond the schema's bare 'symbol' title. However, it does not explain the expected format or provide examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides expiries and strikes for an option chain symbol. It has a clear resource and information scope, but does not explicitly use a verb like 'retrieve' or 'list' and does not differentiate from siblings like index_option_chain or equities_option_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It only states what the tool does, with no mention of use cases, prerequisites, or comparisons to sibling tools such as index_option_chain or trade_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the data is 'live' and covers 'all contracts of a symbol', which is minimal behavioral information. However, it omits any details about response format, rate limits, permissions, or whether it returns only current data or any other operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key information ('Live F&O quotes') and every word adds value. There is no fluff or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and only one simple parameter, the description is minimal. It does not explain what the quote data includes (e.g., LTP, bid, ask, OI) or differentiate clearly from sibling tools like 'live_fno'. An agent would not know what to expect in the response or when to prefer this over a close alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'symbol' with only a title and no description, so schema description coverage is 0%. The description adds some meaning by stating 'of a symbol', implying the parameter is the underlying symbol for F&O contracts. However, it does not specify the expected format (e.g., NSE symbol format) or any constraints beyond the schema's type and required flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing live F&O quotes for all contracts of a symbol, which conveys the resource and scope. It distinguishes from 'stock_quote' (likely spot quotes) and 'live_fno' (possibly broader or different scope). However, it lacks an explicit action verb like 'get' or 'retrieve', relying on the noun phrase 'quotes', so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as 'live_fno' or 'stock_quote'. There are no contextual hints, exclusions, or alternative mentions. It simply states what the tool does without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only identifies the resource as an option chain, but does not describe return format, data coverage, or confirm it is read-only. This is minimal and leaves behavior unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler or redundancy. It front-loads the essential information and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only one sentence, the description is too sparse to fully inform an agent about invocation behavior and return data. It does not mention output composition or parameter constraints, making it incomplete even for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with 0% description coverage, and the description does not explain the symbol parameter or expected format. The default 'USDINR' and the phrase 'currency pair' offer a hint, but the description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns an option chain for a currency pair, clearly identifying the resource and scope. It distinguishes from sibling tools like index_option_chain and equities_option_chain by specifying currency pair, though it lacks an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Option chain for a currency pair' gives a clear context for when the tool applies, but it does not explicitly mention alternative tools or when not to use it. Usage is implied by the asset-class scope rather than stated with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It mentions the categories of output but does not explain any behavior such as sorting order, market scope, time period, or whether it is read-only. This is a significant gap for a tool with no schema details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key content. Every word earns its place, with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain the return structure more thoroughly. It only lists categories but not whether the output is an array of symbols, prices, percentage changes, or other fields. This leaves the agent uncertain about the exact data format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for 0 params is 4, and the description appropriately adds no parameter-specific details but clarifies what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's output as top gainers, losers, most active, and 52-week high/low stocks. This distinguishes it from siblings like stock_quote (individual quotes) and market_status (market overview), though it lacks an explicit action verb like 'fetch' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, no prerequisites, and no exclusions. It simply lists content, leaving the agent to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It states the generic content (order book depth and trade info) but does not mention whether data is real-time, historical, paginated, or any special constraints. This is minimal disclosure beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that directly communicates the tool's purpose without extraneous detail. It is front-loaded and easy to parse, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description provides a high-level purpose but lacks details about the return format, data granularity, or specifics of the trade information. It is adequate for basic selection but not thorough enough for full invocation confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must clarify the 'symbol' parameter. It only repeats that the data is 'for a symbol,' not adding format, examples, or permissible values. The parameter name is self-explanatory, but the description offers no additional value beyond the schema's title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Order book depth and trade information for a symbol' clearly states the tool's purpose and resource. It distinguishes from siblings like stock_quote or chart_data by specifying the data type (order book depth and trades), though it doesn't explicitly name alternatives. The verb is implied rather than explicit, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when order book depth or trade information is needed, providing a clear context. However, it offers no explicit guidance on when to choose this over related tools like stock_quote or chart_data, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the data content ('NSE trading holidays') but does not describe what the tool returns, whether it covers a specific year, or any other behavioral trait. This is a minimal disclosure that goes little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—four words—with no wasted text. It is front-loaded and easy to parse. However, it is slightly under-specified, so it doesn't earn a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns or at least hint at the data structure. 'NSE trading holidays' gives the topic but not the shape of the result (e.g., a list of dates, perhaps with names or day-of-week). Given the low complexity, a small amount of additional detail would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%, so there is nothing to explain. Per the rubric, a baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'NSE trading holidays', which clearly identifies the resource as the list of National Stock Exchange holidays. Although it lacks an explicit verb, the tool name 'holiday_list' supplies the action, and it is distinct enough from sibling tools like 'market_status' or 'trade_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for checking NSE trading holidays, but it does not explicitly say when to use it, when not to, or mention any alternatives. The usage context is straightforward and self-evident, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It only states a fact ('Today's NSE market turnover') and offers no detail about return format, whether it includes delivery and derivative turnover, or how it behaves outside market hours. This is insufficient for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and free of unnecessary words. It clearly states the subject (NSE market turnover) and the time scope (today), making it highly concise without being overly vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no output schema), and the description provides the essential idea. However, it does not explain the meaning of 'turnover' or clarify any date/time semantics (e.g., if it reflects the current session or the last completed day). The absence of annotations and output schema increases the need for more context, which the description does not fully meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema is empty, so per the rubric the baseline is 4. The description adds no parameter-specific information, but none is needed. No gaps exist in parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: NSE market turnover for today. Although it lacks an explicit action verb, the noun phrase effectively communicates what the tool provides. It does not distinguish among sibling tools like trade_info or market_status, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of exclusions or preferred contexts, and the description does not reference sibling tools such as trade_info or market_status. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states the output is 'open or closed' but does not clarify whether the status is real-time, delayed, or based on a specific date/timezone, nor does it describe the response format beyond the binary outcome. This is minimal disclosure for a tool that might have nuances around market hours and holidays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is fully front-loaded and contains no filler. Every word contributes to conveying the tool's core purpose, making it exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema), the description provides adequate information for basic selection and invocation. It states the tool returns the current NSE market status as open or closed, which is sufficient for a simple status check. However, it could be more complete by mentioning whether it reflects the official trading session or if it has any latency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because there are none to document, and the schema is empty, leaving no ambiguity about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides the current NSE market status, indicating whether it is open or closed. This is a specific resource (NSE market) and a definable outcome, distinguishing it from siblings like index_pe_history or stock_quote. It lacks an explicit verb like 'retrieve' or 'get,' but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as pre_open_market or holiday_list. The description does not mention exclusions, prerequisites, or scenarios where this tool is preferred, leaving the agent to infer appropriateness from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It only adds a date format note (YYYY-MM-DD). It does not disclose whether data is daily, how far back history goes, whether index names require a specific format, or what the return structure looks like. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a date format note, front-loading the key action and resource. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple historical data tool, the description covers core purpose and date format, but lacks information about accepted name values, data frequency, and response structure. Without annotations or output schema, it leaves gaps, though the tool's simplicity mitigates this somewhat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists three parameters (name, from_date, to_date) with no descriptions. The description clarifies date format but provides no guidance on what 'name' should contain (e.g., index symbol, full name) or whether dates are inclusive. With 0% schema coverage, this insufficiently compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: retrieving historical valuation metrics (P/E, P/B, dividend yield) for an index. This distinguishes it from siblings like index_history, which likely provides price history. The specific metrics make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when historical valuation ratios for an index are needed, but it does not explicitly state when to prefer this over index_history or stock_history, nor does it mention any exclusions or prerequisites. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Live quote' without explaining what data is returned, whether it is real-time or delayed, rate limits, or any other operational behavior. This is a significant gap for a tool expected to fetch dynamic market data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loads the key action ('Live quote'), and includes an example. Every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers purpose and parameter semantics. However, given the presence of sibling tools (e.g., stock_quote_fno, trade_info) and no annotations, it lacks guidance on return values, data freshness, or how it differs from similar tools. This makes it minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter 'symbol' is described generically in the schema. The description adds meaning by specifying it as an NSE equity symbol and providing an example ('RELIANCE'), which clarifies the expected value. However, it could further explain case sensitivity or symbol format, so a perfect score is not warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'Live quote' for an 'NSE equity symbol' with a concrete example ('RELIANCE'). It differentiates from sibling stock_quote_fno by specifying equity vs F&O, and the verb 'quote' despite being a noun conveys the action of retrieving a quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool: for NSE equity symbols. The example 'RELIANCE' reinforces the equity focus, which distinguishes it from stock_quote_fno (likely for F&O). However, it does not explicitly state when not to use it or name any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nse-mcp MCP server](https://glama.ai/mcp/servers/jugaad-py/nse-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jugaad-py/nse-mcp)

Score Badge

Copy to your README.md:

[![nse-mcp MCP server](https://glama.ai/mcp/servers/jugaad-py/nse-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jugaad-py/nse-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jugaad-py/nse-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server