Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@India Market MCP Show me the live Nifty 50 index value"
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.
Comprehensive MCP server for the Indian stock market — 60 tools covering NSE/BSE, F&O, Mutual Funds, Technicals, ETFs, Commodities, Currencies, Screeners, and more.
Built by combining the best features from 5 open-source Indian market MCP servers. No API keys required.
Module | Tools | What It Covers |
Stocks | 11 | Live quotes, history, financials, peers, corporate actions, peers |
Derivatives | 15 | Option chain, Greeks, max pain, PCR, OI analysis, strategies, margin |
Indices | 3 | All NSE indices, constituents, sector performance |
Mutual Funds | 8 | 47,000+ AMFI schemes, NAV history, comparison, SIP/XIRR calculators |
Market | 11 | FII/DII, IPOs, market breadth, block/bulk deals, dividends, holidays |
Technicals | 3 | SMA, EMA, RSI, MACD, Bollinger Bands, support/resistance, candlestick |
Additional | 9 | ETFs, commodities, currencies, sovereign gold bonds, stock screener |
Related MCP server: Indian Market MCP
cd india-market-mcp
pip install -e .Add to your MCP config:
{
"mcpServers": {
"india-market": {
"command": "python",
"args": ["-m", "src.server"],
"cwd": "D:\\Default Project\\nse-mcp-servers\\india-market-mcp"
}
}
}opencode mcp add india-market -- python -m src.servermcp dev src/server.pyget_stock_quote — Live quote with price, volume, P/E, 52-week range
search_stocks — Search NSE by name or symbol
get_stock_history — Historical OHLCV data (1d/1wk/1mo intervals)
get_top_gainers_losers — NSE top movers with % change
get_52_week_high_low — Stocks near 52-week extremes
get_corporate_actions — Dividends, splits, bonuses
get_stock_financials — Revenue, profit, margins, balance sheet
get_stock_peers — Compare against sector peers
get_market_cap_ranking — Rank stocks by market cap
get_stock_returns — 1M, 3M, 6M, 1Y, 3Y, 5Y returns
get_delivery_volume — Delivery vs intraday volume analysis
get_option_chain — Full option chain for any F&O symbol
get_expiry_dates — Available expiry dates
get_spot_price — Current underlying price
calculate_greeks — Black-Scholes Greeks calculator
calculate_iv — Implied volatility from market price
get_max_pain — Max pain strike price
get_pcr — Put-Call Ratio by OI and volume
get_oi_analysis — Open interest build-up / unwinding
get_top_oi_gainers — Largest OI change strikes
build_strategy — Iron condor, straddle, strangle, butterfly, spread
calculate_margin — Expected margin for F&O positions
get_option_premium — Theoretical premium from Black-Scholes
get_atm_straddle_premium — ATM straddle premium and IV
get_itm_otm_options — Classify strikes as ITM/ATM/OTM
calculate_position_size — Kelly Criterion / risk-based sizing
get_all_indices — All NSE indices with live values
get_index_constituents — All stocks in an index with prices
get_sector_performance — Sectoral indices ranked by performance
search_mutual_funds — Search 47,000+ AMFI schemes
get_mf_nav — Latest NAV
get_mf_history — Full NAV history
get_mf_details — Fund house, category, AUM, expense ratio
compare_mf — Side-by-side comparison of 2–4 funds
analyze_mf — Risk metrics, alpha, Sharpe, Sortino
calculate_sip — SIP future value calculator
calculate_xirr — XIRR from irregular cashflows
get_market_status — Is NSE open/closed/pre-market
get_fii_dii_data — Foreign & domestic institutional flows
get_advances_declines — Market breadth
get_upcoming_ipos — Current & upcoming IPOs
get_past_ipos — Recently listed IPO performance
get_market_announcements — NSE announcements & circulars
get_top_market_news — Market news headlines
get_block_deals — Block deal activity
get_bulk_deals — Bulk deal activity
get_dividend_calendar — Upcoming ex-dividend dates
get_market_holidays — NSE trading holidays
get_technical_indicators — SMA, EMA, RSI, MACD, Bollinger Bands
get_support_resistance — Pivot point S/R levels
detect_candlestick_patterns — Doji, hammer, engulfing, etc.
get_all_etfs — NSE ETFs with live prices
get_etf_quote — Detailed ETF quote
get_commodity_price — Gold, Silver, Crude, Natural Gas
get_all_commodity_prices — All commodities at once
get_currency_rate — USD/INR, EUR/INR, GBP/INR, JPY/INR
get_all_currency_rates — All major pairs
get_sgb_prices — Sovereign Gold Bond live prices
get_stock_screener — Multi-criteria stock screening
get_sector_stocks — All stocks in a sector
NSE India — Live market data, option chains, IPOs, FII/DII, announcements
Yahoo Finance — International data, technical indicators, commodities, currencies
AMFI — 47,000+ mutual fund schemes and NAV history
Results are cached to disk (.cache/india-market-mcp/) with TTLs ranging from 30s (live data) to 1h (static data). Cache size limit: 500MB.
NSE API calls are rate-limited to 1 request every 350ms with automatic retry on 401/403 responses and session re-initialization.
MIT
Deep mutual fund analysis — returns, Sharpe ratio, max drawdown.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions three metrics but omits details on data source, recency, calculation methods, or potential limitations, leaving the agent with insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively communicates the tool's purpose and key outputs, with 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?
With one parameter, no output schema, and no annotations, the description should cover return format and prerequisites. It only states the analysis type and examples, leaving significant gaps for reliable agent invocation.
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 sole parameter scheme_code lacks any description in the input schema (0% coverage), and the tool description does not elaborate on its meaning or format, adding no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs deep mutual fund analysis and lists specific metrics (returns, Sharpe ratio, max drawdown), which distinguishes it from siblings like get_mf_nav or compare_mutual_funds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for in-depth analysis of a single fund but does not explicitly state when to use this tool versus alternatives like get_equity_scheme_performance, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build an options strategy with real market prices. Strategy: iron_condor, bull_call_spread, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| expiry | Yes | ||
| symbol | Yes | ||
| strikes | No | ||
| strategy | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Says 'with real market prices', hinting at live data usage, but does not disclose if execution-related, authentication needs, or potential side effects. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but missing structured information. Could be organized with parameter details while maintaining brevity.
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?
Tool has 4 parameters (3 required) and no output schema; sibling tools include many strategy/calculation tools. Description fails to explain return value (e.g., what does 'build' produce?), prerequisites (e.g., must call get_option_chain first?), or how the strategy is constructed—leaving significant 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?
Schema coverage 0%, so description must compensate. Only 'strategy' is exemplified with types; 'symbol', 'expiry', and 'strikes' are not explained. Adds little meaning beyond schema titles.
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 verb 'build' and resource 'options strategy'. Lists example strategies (iron_condor, bull_call_spread). However, does not differentiate from sibling tools like list_strategies or calculate_option_price, which could also relate to strategy construction.
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 alternatives (e.g., calculating theoretical prices or listing strategies). Implies it uses real prices, but doesn't explain the distinction from calculating theoretical prices or other analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate option Greeks (Delta, Gamma, Theta, Vega, Rho) using Black-Scholes. T = time in years to expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| K | Yes | ||
| S | Yes | ||
| T | Yes | ||
| r | No | ||
| sigma | No | ||
| option_type | No | call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions the Black-Scholes model and T's unit. Missing are behavioral traits such as whether it uses current market data, assumptions (log-normal returns), or any side effects. The description is too sparse to inform the agent about operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences with no redundancy. It front-loads the key action and lists the Greeks. However, it could be slightly expanded for clarity without losing conciseness.
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 output schema and annotations, the description should cover inputs and outputs. It lists the Greeks but doesn't describe the return format (e.g., JSON with Greek values). The 6 parameters are poorly explained. The description is incomplete for an agent to use confidently.
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 0%, so the description must explain parameters. It only clarifies T (time in years). S, K, r, sigma, and option_type remain unexplained. Defaults for r and sigma are in the schema but not described. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates option Greeks (Delta, Gamma, Theta, Vega, Rho) using Black-Scholes. The verb 'calculate' and the specific resource 'option Greeks' make the purpose unambiguous. Among sibling tools, this is distinct from price or IV calculators, though not explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when Greeks are needed, but provides no guidance on when to prefer this over alternatives like 'calculate_option_price' or 'calculate_iv'. No exclusions or context for selection are given, 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.
Calculate Implied Volatility from market price using Newton-Raphson.
| Name | Required | Description | Default |
|---|---|---|---|
| K | Yes | ||
| S | Yes | ||
| T | Yes | ||
| r | No | ||
| option_type | No | call | |
| market_price | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacking annotations, the description must disclose behavioral traits. It mentions the Newton-Raphson method but omits important details such as convergence criteria, sensitivity to initial guesses, error conditions, or whether the calculation works for all option types. The description provides minimal insight into the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. It contains no redundant information, but its brevity may sacrifice necessary details for completeness.
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 implied volatility calculation (6 parameters, numerical method), the description is too minimal. It fails to mention output format, assumptions, or limitations. No output schema is provided, so the agent lacks information about what the tool returns.
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 0% schema description coverage and no parameter explanations in the description, the meaning of parameters S, K, T, r, option_type, and market_price is not explained. The description adds no value beyond the schema's parameter names and types, leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates implied volatility using the Newton-Raphson method, specifying the resource and method. This differentiates it from sibling tools like calculate_option_price (which computes option price) and calculate_greeks (which computes sensitivities).
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 on when to use this tool versus alternatives like calculate_option_price or calculate_greeks. The description does not mention prerequisites, constraints, or exclusions, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate Max Pain strike price for an option chain.
| Name | Required | Description | Default |
|---|---|---|---|
| expiry | No | ||
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it calculates Max Pain but does not disclose whether it is read-only, how it processes data, or any limitations. It is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary context. It is front-loaded with the core purpose, but the brevity sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that calculates max pain (involving option chain data, strike prices, open interest), the description is extremely incomplete. There is no output schema, no explanation of return values, and no context to help the agent understand the tool's role among many siblings.
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 two parameters (symbol, expiry) with zero description coverage. The description adds no additional meaning or guidance on how to use these parameters, leaving the agent with only parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates the Max Pain strike price for an option chain, which is a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'get_option_chain' or 'calculate_greeks', though the name is distinct.
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 alternatives. There is no mention of prerequisites (e.g., needing option chain data) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate theoretical option price using Black-Scholes model.
| Name | Required | Description | Default |
|---|---|---|---|
| K | Yes | ||
| S | Yes | ||
| T | Yes | ||
| r | No | ||
| sigma | No | ||
| option_type | No | call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description must carry behavioral transparency. It mentions Black-Scholes but does not disclose assumptions (European, no dividends), output format, or limitations such as not supporting American options or dividend adjustments.
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 sentence is concise and front-loaded with the core action. However, it could include brief parameter hints or output type without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the one-sentence description is too brief. It lacks context on return value, model assumptions, and when to prefer it over sibling tools like calculate_greeks or get_option_chain.
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 0%, yet the description adds no explanation for parameters like S, K, T, r, sigma, or option_type. While symbols are conventional, the description does not compensate for the missing schema descriptions, leaving meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it calculates theoretical option price using Black-Scholes, a specific model. The verb 'calculate' and resource 'option price' are precise, and it distinguishes from siblings like calculate_greeks or calculate_iv.
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 on when to use this tool versus alternatives like calculate_greeks or get_option_chain. The description implies its use for pricing but lacks explicit when/not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate SIP maturity value and total investment.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | ||
| monthly_amount | Yes | ||
| annual_return_pct | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits such as the compounding frequency, formula used, or assumptions. The output is not described, leaving the agent unaware of what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks necessary detail. It is under-specified for a tool with three parameters and no other structured 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?
Given the absence of annotations, output schema, and parameter descriptions, the description is highly incomplete. It fails to provide enough context for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should explain the parameters but does not. The parameter names are self-explanatory, but no additional meaning is added (e.g., monthly_amount is monthly investment, annual_return_pct is expected return, years is duration). This is insufficient.
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 'Calculate SIP maturity value and total investment' clearly states the verb and resource, and the tool name reinforces this. There is no direct sibling tool for SIP, so differentiation is not an issue, but it's not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like lump sum calculators or other return tools. There is no context for when it is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate XIRR for irregular cash flows. Cashflows: [{"date": "YYYY-MM-DD", "amount": 5000}]
| Name | Required | Description | Default |
|---|---|---|---|
| cashflows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It only gives a cashflow format example, omitting important details like sign convention for cash flows, return format, error handling, or any assumptions.
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 very short and to the point, with no redundant information. However, it sacrifices completeness for brevity.
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 XIRR calculation and the lack of annotations and output schema, the description is incomplete. It fails to explain return values, acceptable inputs, or common use cases, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (items: {}), so the description must compensate. It provides an example JSON structure for the cashflows parameter, adding meaning beyond the schema, but lacks a formal definition or explanation of fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates XIRR for irregular cash flows and provides a format example for the cashflows array. It distinguishes from related tools like calculate_sip_returns, but could be more explicit about the distinction.
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 on when to use this tool versus alternatives, nor any prerequisites, limitations, or context. Users are left to infer usage from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-4 mutual funds side by side.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme_codes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'compare 2-4 funds side by side' without disclosing what data is compared, output format, or any side effects. This lacks transparency for a comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 8 words, front-loaded with key action. Efficient but could include more detail without harming conciseness, such as what aspects are compared.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and minimal description. For a comparison tool, missing details on what data is compared (e.g., returns, NAV) and output format. Incomplete for effective 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?
Single parameter 'scheme_codes' has no description in schema (0% coverage). Description does not explain what scheme codes are or how they map to funds. No value added beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'compare', resource 'mutual funds', and scope '2-4 funds side by side'. This distinguishes it from siblings like 'analyze_mutual_fund' which likely analyzes a single fund.
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?
Implicitly indicates use for comparing multiple funds, but no explicit when-not or alternatives. Siblings exist for single-fund analysis or specific data, but not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect candlestick patterns — Doji, Hammer, Engulfing, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose any behavioral traits such as output format, time range for pattern detection, or any limitations. The agent has no idea what to expect from the tool.
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 extremely concise at one sentence, but this conciseness comes at the expense of completeness. It is front-loaded with the action but lacks necessary detail, making it barely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and no annotations, the description should provide more context. It fails to explain what the tool returns, how to interpret results, or any usage constraints. The agent is left blind.
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 sole parameter 'symbol' has no description in the schema (0% coverage), and the tool description adds no meaning beyond the parameter name. The agent gets no help understanding what symbol format or market is expected.
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 'Detect' and the resource 'candlestick patterns', with examples like Doji and Hammer. This distinguishes it from sibling tools such as get_technical_indicators or get_support_resistance, which focus on different aspects.
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 alternatives, nor does it mention any prerequisites or exclusions. It merely states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate SPAN + Exposure margin for option strategies.
| Name | Required | Description | Default |
|---|---|---|---|
| lots | No | ||
| strategy | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states the estimation action, but does not mention authentication needs, rate limits, or whether the tool modifies any state. The description does not go beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not front-load key information or organize details. More content could be added without sacrificing conciseness.
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 two parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, what 'SPAN + Exposure' means, or how the strategy parameter should be structured. The agent lacks essential 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 two parameters (lots, strategy) with zero schema description coverage. The description does not explain their meaning, valid formats, or how to specify the strategy. The agent must guess based on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it estimates SPAN + Exposure margin for option strategies, which is specific and actionable. However, it does not differentiate from sibling tools like calculate_greeks or build_strategy, missing an opportunity to clarify its unique role.
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 alternatives (e.g., for pre-trade margin estimation vs. actual margin calculation). The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stocks at 52-week high on NSE.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but does not disclose behavioral traits such as read-only nature, output format, or any limitations. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words, earning its place efficiently.
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 tool with no parameters, the description is adequate but could be improved by mentioning what the output contains (e.g., list of symbols or prices). It lacks completeness about the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter info, meeting the baseline 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' and the resource 'stocks at 52-week high' on NSE, differentiating it from siblings like get_52week_low and get_stock_quote.
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 alternatives or when not to use it. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stocks at 52-week low on NSE.
| 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 full responsibility for behavioral disclosure. It does not mention whether the tool is read-only, has rate limits, or how many stocks are returned. The description is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short, front-loaded sentence with no waste. It is concise but could be slightly expanded to cover missing details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is minimally adequate. It identifies the tool's purpose but does not explain the return format, update frequency, or any filtering criteria. This is a simple tool, but more completeness would help an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (0 params), so the schema coverage is 100%. The description does not need to add parameter details. However, it could optionally describe the output format, but baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'stocks at 52-week low on NSE', distinguishing it from siblings like 'get_52week_high' or 'get_top_losers'. However, it lacks explicit differentiation from similar tools and could be more specific about the output.
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 on when to use this tool versus alternatives such as 'get_52week_high' or 'get_top_gainers'. The description provides no context about typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get market breadth — advances vs declines.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description solely bears the burden of disclosure. It only states the tool retrieves advances vs declines without mentioning data source, time period, or any limitations. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose without any filler or redundancy, achieving maximum conciseness.
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 parameterless tool, the description captures the essence, but it lacks details on output structure or interpretation (e.g., raw numbers or ratio). This is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description does not need to explain parameters. However, it adds no information about the output format, which could be helpful for a parameterless tool.
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 market breadth — advances vs declines' clearly states the tool retrieves the aggregate number of advancing and declining stocks, distinguishing it from sibling tools like get_top_gainers that return individual stock lists.
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 alternatives like get_top_gainers or get_most_active. However, the name and description imply it's for market breadth analysis, which is a standard use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get prices for major commodities — Gold, Silver, Crude Oil, Natural Gas.
| 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 full responsibility. It correctly implies a read-only operation but does not disclose any behavioral traits such as authentication requirements, rate limits, or return format. The lack of parameters and simple nature partially mitigate this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without any superfluous words. Every part of the sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description could be more complete by specifying the output structure (e.g., an object with commodity names as keys). However, the examples and sibling context partially compensate for this lack.
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 zero parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter information, which is acceptable as 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 clearly specifies the action ('Get prices') and the resource ('major commodities') with concrete examples (Gold, Silver, Crude Oil, Natural Gas). It distinguishes itself from sibling tools like get_commodity_price which is likely for a single commodity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing the specific commodities included, implying this should be used when all major commodity prices are needed. However, it does not explicitly contrast with the singular get_commodity_price sibling or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all major INR exchange rates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose what 'major' means, data freshness, or that it is a read operation. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no extra words. Efficient and immediately conveys purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is adequate for a simple list tool, but fails to define 'major' or return format, leaving some ambiguity.
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?
Tool has zero parameters, so schema coverage is 100%. Baseline is 4. The description correctly implies no input is needed, adding no further parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('major INR exchange rates'), clearly distinguishing it from the sibling 'get_currency_rate' (which likely returns a single rate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for retrieving all rates, but does not explicitly state when to use this vs. 'get_currency_rate' or other tools. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all NSE ETFs with current prices.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description simply states it gets all ETFs with prices. It does not disclose any behavioral traits such as pagination, data freshness, or rate limits. Adequate for a simple retrieval tool but insufficient detail.
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 sentence, front-loaded purpose, no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is sufficient for a simple list tool. However, lacks details on response format or data scope; still mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is 100%. Per guidelines, baseline is 4 for no params. Description adds no extra meaning since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'all NSE ETFs with current prices', clearly distinguishing it from sibling tools like get_etf_quote which targets individual ETFs.
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 vs alternatives, but the context of 'all' and 'ETF' implies it for listing purposes. Minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all NSE indices with current values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action without disclosing behavioral traits like pagination, rate limits, or response structure. Minimal insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no unnecessary words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It covers the purpose but lacks details about the return format or field names. Adequate but not rich.
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?
No parameters exist, and schema description coverage is 100%. The description correctly implies no input is needed, earning a baseline of 4.
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', the resource 'all NSE indices', and the data 'current values'. It effectively distinguishes from sibling tools like get_index_constituents and get_sector_performance.
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. However, the context is clear enough as a general list tool, so a baseline score is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent block deals on NSE (trades >= 10 crore).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, data freshness, or limitations. It only states the data criterion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose without any superfluous 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?
While the description covers the basic purpose and threshold, it lacks details on return format, recency, pagination, and differentiation from get_bulk_deals. More context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage, so the description's lack of parameter details is acceptable. It implicitly conveys no arguments needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent block deals on NSE with a minimum trade size of 10 crore, effectively distinguishing it from similar tools like get_bulk_deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for large trades on NSE but provides no explicit guidance on when to use or not use this tool compared to alternatives such as get_bulk_deals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get upcoming board meeting dates for corporate actions.
| 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 full burden. It only states the output is 'dates', but fails to disclose whether it returns a list, the next meeting, format, rate limits, or any side effects (likely none).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-informative for a tool with no parameters and no output schema. It doesn't earn its place by adding crucial details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should clarify return format. It only says 'dates', not whether it's a list, dates in what format, or if it covers a specific timeframe. Inadequate for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, which is fine. Baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('upcoming board meeting dates'), distinguishing it from sibling tools which focus on stock quotes, history, etc. However, 'for corporate actions' is slightly vague.
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 on when to use this tool vs. alternatives. With many siblings, it would help to specify that this is for upcoming dates only, or that it complements 'get_corporate_actions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent bulk deals on NSE.
| 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 burden. It only states 'recent', which is vague and does not disclose data volume, frequency of updates, or any potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous information. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is adequate but minimal. It could be improved by clarifying what 'recent' means (e.g., time frame) or what data fields are 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?
There are no parameters, so the baseline is 4. The description does not need to elaborate on parameters, and it correctly implies no input is required.
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' and the resource 'recent bulk deals on NSE'. It is specific and distinguishes from sibling tools like get_block_deals which deals with block deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing bulk deals, but does not provide explicit when-to-use or when-not-to-use context, nor does it compare to alternatives like get_block_deals or get_nse_announcements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get commodity price (Gold: GC=F, Silver: SI=F, Crude: CL=F).
| Name | Required | Description | Default |
|---|---|---|---|
| commodity | No | GC=F |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Get' indicating a read operation, but no details on side effects, authentication, rate limits, or return behavior. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with examples. No filler or redundancy. Front-loaded with verb and resource.
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 simplicity, the description lacks any explanation of what is returned (e.g., current price, change, etc.). No output schema and no annotations, so description should cover more. Incomplete for an agent to understand full 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 has 0% coverage, but description gives three example values (GC=F, SI=F, CL=F) which adds meaning. However, it doesn't explain the default, accepted values, or format. Partially compensates for schema gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get commodity price' with specific examples (Gold, Silver, Crude) and tickers, making the purpose unambiguous. It effectively distinguishes from siblings like 'get_spot_price' by focusing on these specific commodities.
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 when-to-use vs alternatives. However, the examples imply usage for those specific commodities, and the tool is simple. Lacks guidance on when not to use or relation to other price tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company financials — income statement, balance sheet, key ratios.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists what is returned but omits details like data timeframe, freshness, or whether it is read-only (implied but not explicit).
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 sentence, no extra words, front-loaded with the verb and resource. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions three components but lacks detail on structure or format. For a simple tool with one parameter, it is adequate but not comprehensive.
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 0%, and the description does not explain the 'symbol' parameter beyond its obvious meaning. No format or example is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves income statement, balance sheet, and key ratios, distinguishing it from siblings like get_stock_quote (price) and get_stock_history (historical prices).
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 on when to use this tool versus alternatives such as screen_by_fundamentals. The description is too brief to provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get corporate actions (dividends, splits, bonuses) for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only mentions the data type. It omits critical details such as read-only nature, data freshness, prerequisites (valid symbol), or response format. This is insufficient for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the key purpose. It is not verbose, but could include more details without losing conciseness.
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, output schema, and parameter descriptions, the description is incomplete. It does not specify return structure, filtering options, or time period, leaving significant gaps 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no additional meaning beyond the schema's 'symbol' parameter. It does not clarify format, case sensitivity, or valid values. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves corporate actions (dividends, splits, bonuses) for a stock, using a specific verb ('Get') and resource ('corporate actions for a stock'). This distinguishes it from sibling tools like get_stock_quote (current price) or get_stock_history (historical prices).
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 alternatives (e.g., when to use get_corporate_actions vs. get_stock_history for event-related queries). The description lacks context for selection among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currency exchange rate (USDINR=X, EURINR=X, GBPINR=X).
| Name | Required | Description | Default |
|---|---|---|---|
| pair | No | USDINR=X |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states a simple action. It does not mention whether the tool supports arbitrary pairs, the format of the result, error conditions, or any limitations. This is insufficient for an agent to predict behavior.
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 extremely concise, front-loaded with the verb, and contains no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should explain the return structure for the single-pair query. It does not, leaving the agent uninformed about the response format. However, for a simple read operation, the basic purpose is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage, so the description must add meaning. It lists three example values (USDINR=X, etc.), giving format hints. However, it does not explain the '=X' suffix or that the parameter is a pair string, leaving gaps for non-INR pairs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get currency exchange rate' with three examples, making the action clear. However, it does not explicitly distinguish from the sibling tool 'get_all_currency_rates', which may cause confusion about 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?
No guidance is provided on when to use this tool versus alternatives like 'get_all_currency_rates'. There is no indication of supported pairs beyond the three examples, nor when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get equity mutual fund performance (1Y, 3Y, 5Y returns).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It states the tool gets performance but does not disclose whether it returns a single value or list, or the data source. It implies read-only behavior, which is safe, but lacks explicit detail on scope or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It efficiently conveys the tool's core 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?
Without an output schema or parameters, the description is minimal. It explains the basic purpose but omits details like whether returns are for a specific scheme or a list, or the format of the output (e.g., percentages). For a simple tool, this is adequate but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description need not add parameter detail. Baseline for 0 params is 4; the description reinforces the tool's purpose but adds no parameter-level nuance.
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 equity mutual fund performance with specific time horizons (1Y, 3Y, 5Y). It distinguishes from siblings like get_mf_nav (NAV) and get_mf_history (historical), which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., compare_mutual_funds, analyze_mutual_fund). It does not mention any prerequisites or context, such as requiring a scheme selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed ETF quote.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'Get detailed ETF quote' without disclosing data source, latency, rate limits, or what 'detailed' entails (e.g., price, volume, bid/ask). Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (5 words) and lacks substance. While concise, it is under-informative for the tool's complexity. It could be improved with more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description fails to explain the quote contents, return format, or any behavioral context. The tool has one required parameter, but the description is insufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning to the 'symbol' parameter beyond the schema; it does not specify format, examples, or constraints. The tool has only one parameter, and the description provides zero additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets an ETF quote with verb 'Get' and resource 'ETF quote'. However, 'detailed' is vague, and the description does not distinguish from sibling tool 'get_stock_quote', though the asset class difference is implied.
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 provided. The description does not indicate when to use this tool over alternatives like 'get_stock_quote' or 'get_all_etfs', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available expiry dates for an F&O symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description offers no behavioral traits (e.g., read-only, data source, rate limits). The description fails to disclose any implications beyond the bare purpose.
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?
Extremely concise single sentence that is front-loaded with the key action and resource. However, it lacks any structured breakdown, which would be helpful even in a short 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?
Given no output schema, no annotations, and 0% schema coverage, the description is insufficient. It omits return format, data shape, and any usage constraints, making it incomplete for a production use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain the 'symbol' parameter (format, examples, constraints). No added value beyond the schema listing it as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'available expiry dates for an F&O symbol', clearly distinguishing it from siblings like get_option_chain or get_futures_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 on when to use this tool versus alternatives; lacks exclusions or context that would help an agent decide between get_expiry_dates and related tools like get_option_chain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FII (Foreign Institutional Investors) and DII (Domestic Institutional Investors) buy/sell data.
| 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 full burden. It states it gets data but does not disclose what is returned (e.g., single value, list, time period, data format) or any behavioral traits like rate limits or data freshness. For a tool with no annotations, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, 15-word sentence that is front-loaded with the action and resource. Every word adds value, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is the only source of information. It is minimal but sufficient for a simple data retrieval tool. However, it lacks details about the output format or time scope, which could be important for correct 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?
The tool has zero parameters and the schema is empty (100% coverage), so the description is the sole source of meaning. It clarifies that the data is about institutional investors and their buy/sell activity. A score of 4 is appropriate as baseline for no params, but it could be more precise about the metrics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as 'FII (Foreign Institutional Investors) and DII (Domestic Institutional Investors) buy/sell data.' This uniquely defines the tool's purpose and distinguishes it from siblings like get_oi_data or market_overview.
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 alternatives. It lacks context such as 'Use this for overall institutional flow data' or mention of prerequisites. The agent must infer usage 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.
Get futures data — lot size, expiry, OI, price.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states what data is returned (lot size, expiry, OI, price). It does not mention whether data is real-time or delayed, any authentication requirements, rate limits, or side effects. The behavioral impact is minimally disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence that lists key data fields. It is front-loaded with the verb and resource. Could be slightly improved by structuring the fields more clearly, but is efficient and not verbose.
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 one simple parameter and no output schema, the description covers the basic return fields. However, it lacks details like data freshness (real-time vs delayed), explanation of acronyms (OI), and example usage. Adequate for a simple tool but has notable 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 single parameter 'symbol' has no description in the schema (0% coverage) and the tool description does not explain the expected format (e.g., ticker, exchange suffix). The description adds no meaning beyond the schema's type definition.
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' and the resource 'futures data' with specific fields (lot size, expiry, OI, price). It distinguishes itself from siblings like 'get_spot_price' and 'get_oi_data' by combining futures-specific information.
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 on when to use this tool versus alternatives like 'get_spot_price' or 'get_option_chain'. No exclusions or context for appropriate usage, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all stocks in an index with live prices.
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | NIFTY 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description shoulders full burden. It only states 'Get... with live prices' but fails to disclose pagination, rate limits, real-time vs delay, authentication, or any other 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?
The description is a single, concise sentence with no wasted words. However, it may be too brief given the lack of annotations and output schema, but still appropriate for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should hint at return format (e.g., list of stocks with price fields). It does not. Also lacks behavioral context for a tool with many siblings, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain the parameter 'index' (e.g., available values, case sensitivity, format). The default 'NIFTY 50' hints at usage but adds no real semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'all stocks in an index' with 'live prices', making the purpose highly specific. It distinguishes from siblings like get_stock_quote (single stock) and search_stocks (by criteria).
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 on when to use this tool vs alternatives (e.g., search_stocks, get_all_indices). No prerequisites or exclusions mentioned, which is problematic with many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get NSE market holidays for the current year.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the resource and time scope but omits details like return format, data freshness, or side effects. For a read-only tool, this is adequate but could be improved.
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 sentence, no unnecessary words. Efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what 'market holidays' includes (e.g., list of dates, types). It is functional but not fully complete for agent decision-making.
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?
No parameters exist; schema coverage is 100%. Baseline 4 applies as description cannot add more for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the specific resource 'NSE market holidays', and the scope 'current year'. It uniquely identifies the tool among many siblings like get_market_status or get_nse_announcements.
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 on when to use versus alternatives or when not to use. The description only states what it does, not the context of use. For a simple tool this is acceptable but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest Indian market news from Google News.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states basic action. No mention of behavior like rate limits, filtering, or that it returns only Indian news (implied but not explicit).
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 sentence with no fluff, but overly brief for a tool with no other documentation. Could expand slightly on what 'latest' means or how news is sorted.
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 simple tool with one parameter and no output schema, description lacks details on return format, categories, or time range. Barely adequate for full understanding.
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?
Single parameter 'count' has no description in schema (0% coverage). Tool description does not explain its meaning or effect, relying solely on default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'latest Indian market news', and source 'from Google News'. It immediately distinguishes from sibling tools focused on stock quotes, indices, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'market_overview' or 'get_sector_performance'. No when-not-to-use or preconditions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if NSE market is currently open, closed, or pre-market.
| 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 burden. It does not disclose any behavioral traits such as data freshness, rate limits, or whether an API call is made. The description is too brief to provide transparency beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly conveys the tool's purpose with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description is complete. It specifies what the tool checks (NSE market status) and the possible outputs (open, closed, pre-market). No additional context is needed given the lack of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100% (trivially). The description adds no parameter info, but none is needed. According to guidelines, baseline for 0 params is 4.
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 'Check' and the resource 'NSE market', and specifies the three possible states (open, closed, pre-market). This distinguishes it from sibling tools that focus on specific data like stock quotes 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?
The description implies when to use (when needing market status), but provides no explicit guidance on when not to use or alternatives. With zero parameters and a straightforward purpose, this is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full historical NAV for a mutual fund scheme.
| Name | Required | Description | Default |
|---|---|---|---|
| scheme_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'full historical NAV' without detailing data range, pagination, rate limits, or safety implications. This is insufficient for an agent to understand side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. It could be restructured to include essential information without reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain what 'full historical NAV' entails, such as date range, frequency, or return format, leaving ambiguity for the agent.
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 0%, and the description does not explain the scheme_code parameter (e.g., format, where to find it). The description adds no value beyond the schema, which is critical given the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full historical NAV for a mutual fund scheme. It specifies the verb and resource, which is sufficiently clear. However, it does not differentiate from sibling tools like get_mf_nav or compare_mutual_funds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks any mention of use cases, prerequisites, or exclusions, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get most traded stocks on NSE by volume.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the purpose and omits details like sorting direction (presumably descending), output format, or any constraints (e.g., 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?
The description is a single, front-loaded sentence with no superfluous words, making it efficient for an agent to parse.
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 one-parameter retrieval tool without an output schema, the description is adequate but could be improved by specifying the sorting direction or typical use cases.
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 0% schema description coverage, the description does not explain the 'count' parameter beyond its name. However, the parameter is simple and its purpose (limiting the number of results) is intuitive, so it adds minimal but adequate meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the most traded stocks on NSE sorted by volume, which is a specific verb-resource combination that distinguishes it from siblings like get_top_gainers or get_top_losers.
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 alternatives. Among many sibling tools for retrieving market data, there is no mention of appropriate contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest corporate announcements from NSE.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as idempotency, rate limits, or data freshness. The description only states purpose without any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence with no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters or output schema, the description is functional but lacks details on output format, recency constraints, or how 'latest' is defined (e.g., number of announcements, time range). Adequate but minimal.
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 and 100% coverage. The description adds no parameter info, which is acceptable because there are no parameters to document. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('corporate announcements'), and source ('NSE'). It is specific enough to distinguish from siblings like get_corporate_actions, though explicit differentiation is missing.
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 on when to use this tool versus alternatives (e.g., get_corporate_actions, get_market_news). No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get open interest data across expiries for an F&O symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks disclosure of behavioral traits such as whether it returns computed or raw data, any prerequisites, or error behavior for invalid symbols.
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 sentence is concise and front-loaded. Meets the minimum efficiently, though one additional clarifying phrase would improve without harming conciseness.
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 tool with 1 param and no output schema, the description omits details like return structure or whether it covers all expiries. Completeness is lacking given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description does not explain the expected format or constraints for the 'symbol' parameter (e.g., NSE format, futures vs options). Leaves ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'open interest data' with scope 'across expiries' and target 'F&O symbol'. It distinguishes from sibling tools like get_option_chain and get_expiry_dates.
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 on when to use this tool versus alternatives. For example, it doesn't clarify that this tool aggregates OI across expiries, unlike get_option_chain which returns per-strike data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full option chain for NSE F&O symbol. Expiry format: DD-Mon-YYYY
| Name | Required | Description | Default |
|---|---|---|---|
| expiry | No | ||
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only gives the expiry format ('DD-Mon-YYYY') but does not mention auth requirements, rate limits, error handling (e.g., invalid symbol), or side effects. The format is parameter-level, not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a format note, both front-loaded. Every word contributes meaning without redundancy. Ideal conciseness for an AI agent to parse quickly.
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 option chain data and no output schema, the description should hint at return fields (e.g., strikes, bid/ask, OI). It does not. Also lacks guidance on output structure or pagination. Incomplete for a data retrieval tool with zero schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds the expiry format 'DD-Mon-YYYY', which is helpful for the 'expiry' parameter. However, it does not clarify the 'symbol' parameter (assumed NSE F&O symbol) or explain the default behavior when 'expiry' is empty (e.g., returns all expiries?). Partial compensation but incomplete.
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 'full option chain', and scope 'NSE F&O symbol'. It effectively distinguishes from sibling tools like get_futures_data (futures) and get_expiry_dates (only expiry dates). The term 'full option chain' implies comprehensive data, making 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.
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 like get_expiry_dates or get_oi_data. The description lacks any context about prerequisites, preferred usage scenarios, or exclusion criteria, leaving the agent to infer 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.
Get recently listed IPOs and their performance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It states it 'Get's data but does not mention whether it is read-only, any authentication requirements, rate limits, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description should clarify what 'recently listed' means (time frame) and what performance metrics are included. It lacks this 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, so schema coverage is 100%. The description adds no parameter detail, but none is needed. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'recently listed IPOs' and adds 'their performance', distinguishing it from siblings like 'get_upcoming_ipos'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for past IPOs but provides no explicit guidance on when to use it vs alternatives such as 'get_upcoming_ipos' or 'market_overview'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Put-Call Ratio (OI-based and Volume-based) with interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors but only mentions the data included; it does not address what happens if symbol is invalid, rate limits, or what 'interpretation' entails.
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 very concise (one sentence) but lacks structure such as separation of purpose from details. Every word earns its place but it is too minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema), the description fails to explain the return format, how interpretation is provided, or any usage context. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the 'symbol' parameter beyond its name. No additional semantics or context added for the single required 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 clearly states the tool retrieves Put-Call Ratio (both OI-based and Volume-based) with interpretation, distinguishing it from siblings like get_oi_data or get_option_chain.
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 on when to use this tool versus alternatives, no prerequisites or exclusions provided. The description is purely definitional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a stock with its industry peers.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, what data it returns, or any side effects. 'Compare' suggests a read operation, but details are absent.
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, clear sentence. Efficient but lacks essential details. Could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is too minimal. It states the high-level purpose but omits what the output contains (e.g., peer list, metrics), return format, or any behavioral traits.
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 has one required 'symbol' parameter with 0% coverage in description. The description does not explain the parameter's meaning or format, leaving the agent to infer. No value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('compare') and the resource ('a stock with its industry peers'). It distinguishes from siblings like 'get_stock_quote' which are for single stock data. Could be more specific about what comparison metrics are provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when stock peer comparison is needed, but provides no explicit guidance on when to use or exclude alternatives. No mention of prerequisites or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get sectoral indices ranked by performance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It fails to mention data freshness, whether read-only, or any side effects. The tool's 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no waste. It is front-loaded with the core action and resource.
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?
While the tool is simple with no parameters and no output schema, the description lacks context like performance metric, ranking basis (e.g., daily return), or data source. More detail is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no parameter info, which is acceptable. The baseline for zero parameters is 4, as the description does not mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('sectoral indices') and the action ('get ranked by performance'). It distinguishes from siblings that deal with individual stocks or other market data, but could be more explicit about what 'performance' entails.
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 alternatives like search_stocks or market_overview. Sibling tools cover similar analysis, and the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all Sovereign Gold Bonds listed on NSE.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read operation with no side effects, but does not disclose rate limits, caching, or any special behaviors. Adequate for a simple GET with zero parameters.
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 sentence front-loads the action and resource. No wasted words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers what the tool does and the exchange, but omits return format or field details. Since output schema is absent, more detail on returned data would improve completeness. Adequate for its simplicity.
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?
No parameters exist, so schema coverage is 100%. Description adds no parameter details, but none are needed. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Get) and the specific resource (Sovereign Gold Bonds listed on NSE). It distinguishes from siblings like get_stock_quote and get_commodity_price, which target different financial instruments.
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 alternatives. However, due to its unique scope (SGBs on NSE), usage context is implicitly clear. Lacks explicit when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current spot/underlying price for any F&O symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'get current' but does not disclose update frequency, latency, read-only nature, or any side effects. Insufficient for a price-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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no waste. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimally complete given one parameter and no output schema. Lacks details on return format or error handling, which would be helpful for an agent.
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 single parameter 'symbol' is not described in the schema (0% coverage), but the description clarifies it expects an F&O symbol, adding some context beyond the bare name. However, format examples are missing.
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 the current spot/underlying price for F&O symbols, specifying the verb and resource. It distinguishes from siblings like get_stock_quote which is for stocks, but could be more explicit about the F&O focus.
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 on when to use this tool versus alternatives like get_stock_quote or get_futures_data. The description omits contexts or prerequisites, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical OHLCV data. Period: 1d,5d,1mo,3mo,6mo,1y,2y,5y,max
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 1y | |
| symbol | Yes |
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 states the tool retrieves OHLCV data but gives no details on data limits, caching, rate limits, or potential pitfalls.
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 extremely concise: two sentences with no unnecessary words. Every piece of information is relevant and efficiently presented.
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?
While the tool is simple, the description does not specify the return format (e.g., date, open, high, low, close, volume columns). With no output schema, this leaves some ambiguity, but given the tool domain it's mostly adequate.
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 0% description coverage. The description adds meaning by listing allowed period values, but provides no extra context for the 'symbol' 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 clearly states the tool retrieves historical OHLCV data, distinguishing it from sibling tools like get_stock_quote which provide current quotes. The list of valid periods adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical data by listing periods, but lacks explicit guidance on when to use vs alternatives or any prerequisites/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live stock quote with price, volume, 52-week range, P/E, market cap.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It lists returned fields but does not disclose behavioral traits such as idempotency, error handling, data freshness, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and to the point, with 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?
The tool is simple with one parameter and no output schema, but the description lacks details on return format, error scenarios, or scope (single stock vs. multiple). It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'symbol' with no description (0% coverage). The description does not explain the format or meaning of 'symbol' beyond implying it is a stock ticker, leaving ambiguity.
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' and the resource 'live stock quote' with specific data fields (price, volume, 52-week range, P/E, market cap). This distinguishes it from siblings like search_stocks or get_stock_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a current snapshot of a stock, but does not explicitly state when to use it versus alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get support and resistance levels using pivot points.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as calculation methodology, data source, or limitations. For a tool with no annotations, the description should provide more context about what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but may be overly brief for a tool that lacks annotations. It front-loads the key action, but more detail could improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate. However, it omits details like return format, pivot point type (e.g., floor, Fibonacci), and whether intraday or daily data is used.
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 0% schema description coverage, the description adds no meaning beyond the parameter name 'symbol'. It does not specify the required format (e.g., ticker symbol, ISIN) or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting support and resistance levels using pivot points. It is specific enough to distinguish it from sibling tools like get_technical_indicators or detect_candlestick_patterns.
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 alternatives (e.g., other technical analysis tools). There is no context about prerequisites, data frequency, or market applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get technical indicators — SMA, EMA, RSI, MACD, Bollinger Bands for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavior like number of data points, time period, calculation parameters, error handling, or whether the symbol must be valid. Merely listing indicators is insufficient for a complete behavioral understanding.
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?
Extremely concise single sentence that front-loads the purpose and lists included indicators. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should hint at return format or data structure, which it does not. It also lacks details on typical parameters like period or interval, leaving agents underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It specifies 'for a stock,' clarifying that 'symbol' is a stock ticker. This adds minimal value beyond the schema's empty title, but does not provide format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get technical indicators') and lists specific indicators (SMA, EMA, RSI, MACD, Bollinger Bands) for a specific resource ('stock'), distinguishing it from sibling tools like get_stock_quote or get_stock_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool versus alternatives. The list of indicators implies use cases for technical analysis, but no exclusions or context for selection among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top gaining stocks on NSE.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully disclose behavioral traits. It does not mention ranking criteria, time period, real-time status, or response limits. Too minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than concise. It could include a bit more detail without adding verbosity.
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 tool, the description lacks essential context such as the structure of the response, time frame of gains, and relationship to similar sibling tools. Incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'count' parameter or its default value. It adds no meaning beyond the schema's type and default.
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 top gaining stocks on NSE' provides a specific verb and resource, clearly distinguishing it from sibling tools like get_stock_quote or get_top_losers. No tautology.
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 given on when to use this tool versus alternatives such as get_top_losers or get_most_active. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top losing stocks on NSE.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose how results are sorted (e.g., by percentage decline), time period, or data source.
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 sentence is concise but overly terse; could specify 'by percentage decline' without sacrificing brevity.
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, annotations, or parameter details, the description is insufficient for an agent to fully understand the tool's capabilities.
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 has 0% description coverage and description does not explain the 'count' parameter, leaving its meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves top losing stocks on NSE, distinguishing it from gainers and activity-based tools.
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 on when to use this tool versus alternatives like get_top_gainers or get_most_active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get upcoming and ongoing IPOs on NSE.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It only states the basic function without mentioning data freshness, pagination, or what fields 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?
The description is a single, efficient sentence with no wasted words, front-loading the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool, the description is adequate. It identifies the resource and scope, but could optionally mention the type of data returned (e.g., IPO names, dates).
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?
No parameters exist, so the baseline is 4 as per guidelines. The description does not add parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', resource 'upcoming and ongoing IPOs', and location 'on NSE'. This is specific and distinguishes it from sibling tools like get_past_ipos.
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 indicates the tool is for current IPO listings but does not explicitly explain when to use it over alternatives or provide context about data refresh frequency or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available option strategies by category.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as authentication needs or side effects. It only states the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information, fitting for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately conveys the purpose. It could mention output format, but it's sufficient for its simplicity.
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, so baseline is 4. The description does not need to add parameter meaning, but 'by category' hints at output structure.
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 lists option strategies by category, which is distinct from sibling tools like build_strategy or get_option_chain. However, 'by category' could be more specific.
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 on when to use this tool versus alternatives. The description is a single sentence without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get NIFTY & BANKNIFTY snapshot — spot, ATM IV, PCR, lot size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description implies a read operation ('snapshot') but does not explicitly state it is non-destructive, permissions required, or rate limits. Basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the purpose and lists key outputs, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description sufficiently explains the tool's function and return data. It is complete for this simple tool, though it could mention update frequency or data source.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by specifying what data is returned (spot, ATM IV, PCR, lot size), which the empty schema does not convey.
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 a snapshot of NIFTY and BANKNIFTY indices, listing specific fields (spot, ATM IV, PCR, lot size). This distinguishes it from sibling tools like get_stock_quote (individual stocks) or get_pcr (single metric).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for overall market overview of two key indices but does not explicitly state when to use vs alternatives or when not to use. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate optimal position size based on capital and risk tolerance.
| Name | Required | Description | Default |
|---|---|---|---|
| capital | Yes | ||
| risk_pct | No | ||
| stop_loss | No | ||
| entry_price | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details like formula used, assumptions, or side effects. Single sentence is insufficient for 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?
Very concise single sentence, but lacks any structure like bullet points or parameter list. Could be more informative without losing conciseness.
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 4 parameters, no output schema, and no annotations, the description is too sparse. Does not explain return value, formula, or edge cases.
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 has 4 parameters with 0% description coverage. Description mentions 'capital and risk tolerance' but does not explain 'risk_pct', 'stop_loss', 'entry_price' meanings or how they relate to calculation.
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 'Calculate' and specific resource 'optimal position size'. Distinct from sibling tools which are mostly data retrieval or analysis.
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 on when to use this tool versus alternatives or when not to use. Only states purpose without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen stocks by fundamental ratios — P/E, ROE, market cap.
| Name | Required | Description | Default |
|---|---|---|---|
| max_pe | No | ||
| min_pe | No | ||
| min_roe | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'Screen stocks'. Missing details on output format, pagination, rate limits, or the fact that market cap is mentioned but not in schema. Discrepancy between described criteria and schema parameters.
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 sentence, front-loaded, no filler. However, given missing critical details, it leans toward under-specification rather than efficient conciseness.
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?
Lacks information about return type, output schema, or how results are delivered. For a screening tool with no annotations, this is insufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain individual parameters (max_pe, min_pe, min_roe) beyond listing example ratios. It adds minimal meaning to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens stocks by fundamental ratios (P/E, ROE, market cap), which is specific and differentiates from sibling tools like 'screen_stocks' that may be broader. However, it doesn't explicitly distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., search_stocks, screen_stocks). No context on prerequisites 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.
Screen stocks by price, volume, and sector filters.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No | ||
| max_price | No | ||
| min_price | No | ||
| min_volume | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Screen' suggests a read-only query, but it does not disclose if results are limited, paginated, or sorted. No mention of side effects or permissions; insufficient for a 'screen' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence of 8 words. Every word adds value; the action and criteria are front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and four parameters, the description should explain what the tool returns (e.g., a list of matching stocks). It omits scope, ordering, and result count, making it incomplete for a screening tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to parameters by naming them as filters (price, volume, sector), which the schema lacks (0% coverage). However, it does not explain parameter interactions (e.g., min_price vs max_price range) or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Screen stocks'. It specifies filters (price, volume, sector) which distinguishes it from siblings like get_stock_quote (single stock) and screen_by_fundamentals (different criteria).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for filtering by criteria but provides no explicit guidance on when to use this over alternatives like search_stocks or screen_by_fundamentals. Context is clear but lacks exclusions or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search mutual funds by name across 47,000+ AMFI schemes.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses the data source ('47,000+ AMFI schemes') and the search criterion ('by name'), which is helpful. However, it does not mention what information is returned (e.g., scheme code, NAV) or any behavioral traits like partial matching or case sensitivity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the core functionality without any superfluous words. It is front-loaded and easy to parse.
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 simplicity of the tool (one parameter, no output schema), the description covers the essential information: what it does and the scope. However, it would benefit from briefly stating the return format (list of schemes) to complete the mental model.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description adds no detail about the 'query' parameter beyond the schema. The description only says 'by name', which loosely implies the query usage, but does not specify format, constraints, or possible values. For a single parameter, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Search', the resource 'mutual funds', and the scope 'by name across 47,000+ AMFI schemes'. This clearly distinguishes it from sibling tools like get_mf_nav or compare_mutual_funds, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for finding mutual funds by name, but does not provide explicit guidance on when to use it versus alternatives such as search_stocks or compare_mutual_funds. No exclusions or contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for stocks by name or symbol on NSE.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only mentions the search capability but omits details like result limits, ambiguity handling, or pagination. This lack of transparency is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. However, it could be slightly expanded to include important context without becoming verbose.
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 simple input (one string parameter) and no output schema, the description is minimally adequate. It identifies the search domain but fails to describe the result format or limitations, which would be expected for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds no additional meaning beyond the parameter name 'query', only stating it searches 'by name or symbol', which is already implied. No format or syntax guidance is given.
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 'search', the resource 'stocks', and the scope 'by name or symbol on NSE'. This is distinct from sibling tools like search_mutual_funds and other retrieval tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_stock_quote (for exact symbol) or search_mutual_funds. The usage is implied for partial matches, but no context or exclusions are provided.
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.0analyze_mutual_fundbuild_strategycalculate_greekscalculate_ivcalculate_max_paincalculate_option_pricecalculate_sip_returnscalculate_xirrcompare_mutual_fundsdetect_candlestick_patternsestimate_marginget_52week_highget_52week_lowget_advances_declinesget_all_commodity_pricesget_all_currency_ratesget_all_etfsget_all_indicesget_block_dealsget_board_meetingsget_bulk_dealsget_commodity_priceget_company_financialsget_corporate_actionsget_currency_rateget_equity_scheme_performanceget_etf_quoteget_expiry_datesget_fii_dii_dataget_futures_dataget_index_constituentsget_market_holidaysget_market_newsget_market_statusget_mf_historyget_mf_navget_most_activeget_nse_announcementsget_oi_dataget_option_chainget_past_iposget_pcrget_peer_comparisonget_sector_performanceget_sovereign_gold_bondsget_spot_priceget_stock_historyget_stock_quoteget_support_resistanceget_technical_indicatorsget_top_gainersget_top_losersget_upcoming_iposlist_strategiesmarket_overviewposition_sizingscreen_by_fundamentalsscreen_stockssearch_mutual_fundssearch_stocksScored across 60 tools
Each tool targets a distinct piece of data or calculation within Indian markets. There's no overlapping purpose; even similar tools like get_top_gainers and get_top_losers are clearly differentiated by their names and descriptions.
Most tool names follow a clear verb_noun pattern in lowercase snake_case, but a few exceptions like 'market_overview' and 'position_sizing' break the pattern by starting with a noun. Overall, the style is consistent and predictable.
With 60 tools, the count is too high for optimal coherence. While the domain is broad, many tools could be merged into parameterized versions (e.g., different top lists or calculation helpers). This number exceeds the 'well-scoped' guideline significantly.
The tool set covers an extremely wide range of Indian market data: stocks, indices, mutual funds, options, futures, commodities, currencies, IPOs, corporate actions, technical analysis, and market news. There are no obvious gaps for a read-only data server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
The Octagon MCP server provides specialized AI-powered financial research and analysis by integrating with the Octagon Market Intelligence API. It enables users to analyze public market data (SEC filings, earnings transcripts, financial metrics, and stock data for 8000+ companies), private market data (3M+ companies, 500k+ funding rounds, 2M+ M&A/IPO transactions), and conduct deep research including web scraping capabilities. The server also features autonomous research agents that search hundreds of sources and return fully cited reports in approximately one minute.
Stock analysis MCP: 38 indicators, 7 optimizers, 8 backtests, US + India sectors.
MCP server for stocksense-ai documentation, generated by doc2mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/icharshal/india-market-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
