MarketPulse MCP
Server Quality Checklist
Latest release: v0.10.0
- Disambiguation2/5
Many tools overlap significantly: multiple quote tools (nse_quote, stock_quote, live_quote, fyers_live_quote, icici_live_quote), multiple portfolio analyzers (portfolio_analysis, analyze_portfolio), and multiple pledge/insider tools. The boundaries between get_stock_brief and get_stock_debate, or dividend_history and dividend_history_deep, are unclear. An agent would struggle to pick the right tool for a given task.
Naming Consistency3/5Most tools use snake_case, but the prefix patterns are inconsistent: some start with nse_, some with stock_, some with get_, some with calculate_, etc. The verb-noun structure is not consistently applied (e.g., 'nse_quote' vs 'get_nifty_outlook'). While readable, the naming lacks a predictable scheme.
Tool Count1/5With 95 tools, this server is extremely bloated. Even for a comprehensive market data platform, 95 tools exceeds any reasonable scope by a wide margin. Many tools are redundant or overly granular, making the surface area unmanageable.
Completeness4/5The server covers an extensive domain: quotes, historical data, fundamentals, options, portfolio analysis, tax, macro indicators, and even sentiment signals. Minor gaps exist, such as no direct trade execution or more exotic asset classes, but for its apparent purpose of Indian market analysis, coverage is thorough.
Average 4.2/5 across 95 of 95 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the outcome (returning metadata/links) without disclosing any behavioral traits such as read-only nature, authentication needs, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no unnecessary information. It is front-loaded with the primary action and is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values don't need to be explained. However, the description is vague about what constitutes 'basic server metadata' and which 'useful links' are included. It is minimally adequate for a simple info tool but lacks specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the schema coverage is 100%, so the description doesn't need to explain parameters. The baseline for zero params is 4, and the description adequately reflects that no inputs are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Return basic server metadata and useful links', clearly identifying the verb and resource. It distinguishes from data-focused siblings but doesn't explicitly differentiate from status/info tools; still, the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no context about its intended use case, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions that the peer basket is 'likely' (hinting at a heuristic nature) but does not disclose data source, freshness, limitations, or error behavior. This leaves the agent uncertain about the reliability and boundaries of the peer-rank and valuation outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by a concise bulleted list of outputs and an Args line. There is no redundant or filler information; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the essential selection and invocation details, including example symbol formats. However, the lack of usage guidance and behavioral context means an agent must infer edge cases and suitability relative to sibling tools, making the description adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares a string property named 'symbol', but the description's Args section adds crucial domain context by specifying NSE symbols and giving three concrete examples (RELIANCE, HDFCBANK, INFY). Since schema description coverage is 0%, this compensation is valuable and makes the parameter unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Sector and peer context for a stock' and lists four concrete outputs (likely peer basket, peer rank, valuation vs peers, sector performance context), clearly identifying the tool's function and scope. However, it does not explicitly contrast with sibling tools like sector_performance or compare_stocks_tool, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance, alternatives, or exclusions. An agent must infer from the name and output bullets that this tool is for single-stock sector and peer comparison, but there is no statement distinguishing it from related tools such as sector_performance or compare_stocks_tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that the tool 'does not claim the full live system has exactly this accuracy' and frames itself as a 'defensible evaluation layer,' which is valuable. However, it does not describe operational details like data sources, what it computes step-by-step, or whether it has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and logically arranged: an opening purpose, important caveats, and parameter definitions. The three 'Important' bullet points are somewhat redundant, all conveying the same honesty message, but the overall length is reasonable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values are covered separately. The description covers purpose, limitations, and parameter meanings, but it lacks a clear explanation of what 'checkpoints' and 'hit evaluation' mean, and it relies on familiarity with the 'signal engine' and 'price-action core.' This makes it incomplete for a new user without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: symbol is an 'NSE symbol', lookback_months is a 'historical window for checkpoints', and holding_days is a 'forward return horizon for hit evaluation'. This adds clear semantic meaning beyond the schema's bare titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description calls the tool a 'Lightweight evaluation / proof layer for the signal engine's price-action core' and emphasizes honesty, but stops short of stating a concrete verb+resource (e.g., 'computes historical accuracy metrics'). It differentiates from siblings only through the 'honesty tool' framing, not through specific functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case ('before making accuracy claims') and positions itself as an honest proof layer, but it does not explicitly state when to use this tool versus alternative tools like get_signal_accuracy or check_signal_outcomes. No exclusions or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently lists the signal inputs and return fields, including a full component breakdown. However, it omits behavioral details such as data recency, latency, or interpretation of 'automation_rank', leaving some ambiguity about what the score truly reflects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate bullet lists for components and returns, and every line adds useful information. It is slightly long but remains efficient and easy to scan for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, inputs, and output fields, and an output schema exists so return documentation is adequate. It lacks a brief note on interpreting the 0-100 signal_score, but overall it provides enough context for a straightforward composite score tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (symbol) with 0% description coverage, and the description offers no additional context about symbol format, exchange, or examples. Since the schema is minimal, the description should compensate but does not, making parameter semantics weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an 'Automation-friendly stock ranking score built from FinStack signals' and lists the signal components and return fields, making its purpose specific. It distinguishes itself from more granular siblings by referencing a composite score, though it does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a consolidated-view use case by listing eight signal categories, but it never states when to choose this tool over individual signal tools like get_social_sentiment or get_insider_signal. The 'automation-friendly' phrase hints at programmatic use but offers no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It lists what data is provided and mentions live data source links, but does not specify data freshness, calculation methodology, or potential delays/latency. It also doesn't mention whether the output is cached or request-time fetched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a header, justification, bullets, and example, but the Bloomberg price comparison sentence is not directly useful for agent invocation. It adds context on why the tool exists but isn't concise. The core data list is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, single-purpose tool with an output schema, the description is fairly complete. It enumerates exact maturities and provides source links, which sets expectations. It doesn't explain return formatting, but the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, and schema coverage is trivially 100%. Description includes a call example, confirming no args needed. No parameter explanation is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides India G-Sec yields from 91-day T-bill to 30-year bond, listing specific maturities. It lacks an explicit imperative verb like 'fetches' but is unambiguous. It doesn't explicitly distinguish from sibling rbi_policy_rates, though the focus on yield curve is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context that RBI/CCIL are free sources vs Bloomberg, implying this is the low-cost way to get bond yields. However, it does not state when to use this vs alternatives like rbi_policy_rates or india_macro_indicators, nor any exclusions. Usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful context about the World Bank source and lists the indicators, but does not disclose data freshness, update frequency, pagination, or any limitations. The example call shows zero parameters, which clarifies the invocation but is not a full behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and front-loaded with the tool's purpose, but includes a tangential pricing paragraph that, while providing context, is not essential for tool invocation. The list and example are well-structured, but the pricing info could be trimmed for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description adequately covers what data is returned, the source, and provides a usage example. The output schema exists to define return structure, so the description fills the semantic gap. It could mention potential missing indicators or update latency, but it's largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to explain parameter semantics. The example call india_macro_indicators() explicitly confirms no arguments are needed, and the empty schema with 100% coverage leaves no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as surfacing India macroeconomic indicators, explicitly listing CPI, GDP, current account, unemployment, etc. It distinguishes from sibling tools like rbi_policy_rates by covering broad macro data, though the verb is implicit ('provides') rather than a direct action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool compared to siblings. The pricing comparison with Bloomberg/Refinitiv is a rationale for using free World Bank data but not a usage guideline. It does not mention alternatives like rbi_policy_rates or india_gsec_yields or when to prefer them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description is the sole source. It notes that recent and historical actions are shown with dates and values, which gives some insight into behavior, but doesn't mention any limitations, error cases, or whether data is real-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main verb, a brief output summary, and a parameter section with examples. Slightly redundant between the first two sentences but remains tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema provided, the description covers the input, output features, and examples adequately. It only misses guidance on selecting this tool among sibling tools, which is already reflected in the usage guidelines dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains the symbol parameter with format examples (ITC, RELIANCE) and states it expects an NSE symbol, adding value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves corporate actions (dividends, splits, bonuses) for an NSE stock, with examples. It distinguishes itself from simple quote tools but doesn't explicitly differentiate from sibling tools like dividend_history, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No mention of when to use this tool versus alternatives such as dividend_history or nse_quote. The examples show usage but no exclusions or context for choosing it over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses setup prerequisites (pip package, env vars, credential URL) and notes 'zero delay when configured.' It also lists return fields. However, it does not describe failure modes, authentication errors, rate limits, or symbol validation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: what it does, what it returns, setup requirements, and arguments. Each sentence adds value and there is no fluff. The core purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter quote tool, the description covers purpose, return data, setup, and parameter format. The presence of an output schema likely covers return structure. Missing elements include usage guidance relative to siblings and explicit error/edge-case behavior, but the description is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It defines the 'symbol' parameter as an NSE symbol with concrete examples (RELIANCE, TCS, INFY), clarifying the accepted format. It does not mention case sensitivity or exchange prefix, but the examples provide practical guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides real-time NSE stock quotes via Fyers API v3 and enumerates the returned fields (LTP, O/H/L/C, volume, change%, 52W high/low). However, it does not explicitly distinguish this from similar siblings like live_quote or stock_quote, relying on 'via Fyers API' as the only differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is provided. The description includes setup instructions but does not explain, for example, when to prefer this over nse_quote or icici_live_quote, or whether it is the only zero-delay option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the source (ICICI Breeze) and enumerates interval options, but does not mention data freshness, coverage limitations, or any non-obvious behavior. It is not misleading, just minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and well-organized, with a clear one-line purpose, an interval options list, and an Args table. Every sentence adds value and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the existence of an output schema, the description covers essential information. It lacks explicit usage context and some behavioral details, but the core details (resource, intervals, parameters) are present. It is not exhaustive but sufficient for a straightforward data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful meaning for all three parameters: symbol is an NSE symbol with an example, interval has allowed values, and days has a default. This goes beyond the bare schema and helps the agent construct correct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as historical OHLCV candles from ICICI Breeze API, which is more specific than the tool name alone. It distinguishes from sibling tools like fyers_candles by naming the broker, though it lacks an explicit verb like 'retrieves' or 'fetches'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as fyers_candles, stock_historical, or nse_historical. The description does list interval options and defaults, but it does not explain the intended use case or differentiation from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It implies a read-only operation via 'Get' and 'Shows' and discloses the output metrics, which is useful. However, it does not mention data source, delay, invalid symbol handling, or any side effects, though for a simple data fetch this is acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary, a brief output description, an args section, and examples. Every sentence adds value and the most important information (what it does) is front-loaded. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema (present but not shown), the description is adequately complete. It states the core metrics returned and gives examples. It does not detail the output schema fields, but the existing output schema handles that, and the description is sufficient for a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type, so the description must compensate. It does so by explaining 'symbol: NSE stock symbol' and giving concrete examples (RELIANCE, TCS, INFY, HDFCBANK), adding meaningful semantics beyond the schema. No additional validation details are provided, but the examples suffice for a single string parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'latest quarterly financial results for an NSE stock' and lists specific metrics (revenue, profit, EPS, EBITDA), giving a specific verb+resource. It does not explicitly differentiate from siblings like income_statement or earnings_calendar, but the focus on quarterly results with growth rates makes the purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it versus alternatives. It does not mention any exclusions, prerequisites, or context such as 'use this for quarterly fundamentals' or 'use nse_quote for current price', leaving the agent without explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It lists the 5 signals and risk levels, but omits time horizon, reliability, data sources, and limitations. The promotional line 'Predicted 4 lower circuits in March' adds no operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and organized with signals and risk levels, but the extraneous marketing quote 'Predicted 4 lower circuits in March — here's how' wastes a line and dilutes the structure. Otherwise, it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single param and presence of an output schema, the description supplies core inputs and output categories. However, it lacks prediction horizon, practical interpretation of risk levels, and caveats, leaving noticeable gaps for a predictive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 'NSE symbol' and a usage hint ('most useful for mid/small caps under stress'), which helps but lacks format examples or validation rules, only partially covering the gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb+resource: 'Predict lower circuit risk for an NSE stock.' It lists five distinct signals and four risk levels, distinguishing it from related siblings like nse_circuit_breakers (actual limits) and detect_unusual_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'most useful for mid/small caps under stress' gives clear context on when to employ the tool. However, it does not explicitly name alternatives or state when NOT to use it, so it stops short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output data (historical dates, amounts, totals, average, latest), but doesn't mention potential errors, data coverage limitations, or any special behaviors. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the main purpose and then providing return details and an Args block. The examples are slightly redundant but serve as useful usage illustrations. It's well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and an output schema, the description covers the essential information: what it does, what it returns, and what the parameter means. It doesn't mention market coverage or edge cases, but the simplicity of the tool reduces the need for deeper context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for parameter descriptions, so the description's 'symbol: Stock ticker (e.g., ITC, COALINDIA, AAPL, MSFT)' adds essential meaning beyond the schema's bare string type. The examples reinforce the expected format, though more detail (e.g., exchange) could be added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get historical dividend payments for a stock' and specifies the exact return data (dates, amounts, totals, average, latest). While this is specific, it does not explicitly distinguish from sibling tools like dividend_history_deep, so it doesn't fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the Args section and examples (e.g., ITC, AAPL), but there is no explicit guidance on when to use this tool versus alternatives such as dividend_history_deep or stock_historical. The context signals and sibling list suggest overlaps but the description doesn't address them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It states the action but doesn't describe side effects, authentication needs, or the nature of the response. This is only marginally more informative than the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, no redundancy. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter status tool with an output schema, the description covers the basic purpose and additional value (setup instructions). It does not over-explain, but also lacks detail on what 'status' means or what the output looks like; however, given the output schema exists, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters means the description doesn't need to explain input semantics. The schema has no properties, so a baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check'), names the resource ('Fyers API v3 configuration'), and adds the output content ('setup instructions'), clearly distinguishing it from sibling market data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives like broker_setup_status or icici_status. It simply presents its function without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the computation logic (pledge %, QoQ change), risk thresholds, and returns. However, it omits important behavioral details such as data freshness, error handling, or whether data is real-time/delayed. The marketing quote ('Caught 3 stocks...') adds little behavioral value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear headline, threshold list, and Args/Returns sections. It is not overly long, but the marketing quote and the explanatory paragraph about pledge mechanics are somewhat extraneous for an agent and could be trimmed without losing essential usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the purpose, inputs, outputs, and risk assessment logic. It is fairly complete, though it could mention data source or limitations, and it does not differentiate from related scanning tools. Overall, this is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbol' as a string, but the Args section provides meaningful elaboration: examples (ADANIENT, ZEEL), format (NSE symbol), and scope ('any stock'). This significantly augments the minimal schema, making it clear what the agent should pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'promoter pledge early warning' tool for NSE stocks, checking pledge percentage and QoQ change velocity. It also provides specific risk levels, distinguishing it from generic pledge data tools. However, it does not explicitly name sibling tools like promoter_pledge or scan_pledge_risks, so it lacks direct sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining the risk mechanism and what it checks, but it does not explicitly state when to use this tool versus alternatives. There is no mention of when to prefer this over promoter_pledge or scan_pledge_risks, and no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure but only offers a conceptual example ('GST from auto sector up 24% YoY → MSIL/Bajaj Auto historically follow in 2-3 months'). It does not describe the calculation method, output format, data freshness, or limitations, leaving significant operational ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and organized with clear sections for sectors and arguments. The example quote adds illustrative value but is slightly redundant; overall, it is concise enough and well-structured without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the purpose, sector list, and parameter usage. It lacks explicit guidance on interpreting the output or handling edge cases, but the output schema can supply return-value details, making the description sufficiently complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema offers no description for 'sector', but the description compensates with an 'Args' section providing examples ('Auto', 'FMCG'), the special value 'all', and a list of supported sectors. This adds meaningful semantics beyond the schema, though it does not specify exact string case or an exhaustive enumeration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'GST collection data → sector performance predictor' and elaborates on the leading indicator concept, listing specific sectors covered. This establishes a distinct purpose compared to generic sector tools, with a clear verb-resource relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining the leading indicator timeframe and sector coverage, but it never explicitly says when to use this tool over alternatives or provides exclusions. No sibling tools are referenced, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool reads multiple data sources and returns a single recommendation, indicating a read-only analysis operation. However, it does not explicitly state that it does not execute trades or mention any limitations, error conditions, or rate implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with its purpose. It lists inputs and outputs efficiently. The phrase 'strongest nifty-agent behavior' is slightly promotional and adds little substance, but overall the text is concise and every other sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple schema (1 optional param) and presence of an output schema, the description provides extra context by enumerating the returned fields (action, confidence, strike zone, factors, risk flags). It does not explain the output schema structure (but that is covered by the schema itself) and lacks usage differentiation, but is otherwise complete for a decision-support tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single 'symbol' parameter. The description mentions NIFTY/BANKNIFTY, which hints at valid values, but it does not explicitly explain that the parameter defaults to NIFTY or that other symbols may be accepted. For a simple optional parameter, this partial compensation is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build a clean NIFTY / BANKNIFTY options setup for intraday decisions.' It specifies the exact outputs (BUY_CE, BUY_PE, NO_TRADE) and additional return fields (confidence_pct, ATM strike zone, etc.), making it distinct from sibling tools that focus on quotes, indicators, or news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context ('for intraday decisions') but does not explicitly mention when to use this tool versus alternatives like get_nifty_outlook or get_morning_fno_brief. No exclusions or alternative tool names are provided, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the dependency on ICICI Breeze, the 'zero delay when configured' conditionality, the need for a daily session token, and lists the output fields. However, it omits behavior on errors, rate limits, or the explicit read-only nature, leaving some important operational traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Returns, Setup, and Args. It front-loads the core purpose and all sentences contribute useful context, especially the setup commands. Though slightly longer than necessary, the setup instructions are relevant for understanding the tool's operational requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter real-time quote tool, the description is largely complete: purpose, return fields, parameter format, and setup prerequisites are covered. The existing output schema would handle detailed return structure, and the description's field listing is a bonus. Missing explicit guidance on when to prefer this over sibling quote tools is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain the parameter. It does this well by defining 'symbol' as 'NSE symbol' and providing concrete examples (RELIANCE, TCS, HDFCBANK). This adds clear meaning beyond the schema's bare 'Symbol' title, though it doesn't address formatting edge cases like case sensitivity or exchange prefixes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool delivers a 'Real-time NSE quote via ICICI Breeze API' and lists the exact fields returned (LTP, O/H/L, previous close, volume, change%). This goes beyond a vague verb+resource, providing a specific data scope that clearly distinguishes it from sibling quote tools such as nse_quote or stock_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives like fyers_live_quote or live_quote. The description includes setup instructions but no comparison, exclusion criteria, or explicit use-case framing. The only implied usage is 'if you have ICICI Breeze credentials,' which is not enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that AUM is approximate and that the tool links to a detailed data portal, which is useful context. However, it does not mention data freshness, update frequency, rate limits, or whether results are cached, which are important behavioral traits for a data retrieval tool in this domain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise and well-structured: it opens with a clear summary, then provides a bulleted list of data types, and closes with an example call. The note about Morningstar Direct's cost is slightly tangential but adds persuasive context about the tool's value proposition, so it earns its place. The overall length is appropriate for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema (though not shown here), the description is quite complete. It lists all the key data types returned, includes a usage example, and establishes the source (AMFI). The only minor gap is not describing the exact output structure, but the output schema already handles that. For a simple tool, this description provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the parameter semantics dimension benefits from the baseline of 4. The description provides ample context about the output (AUM, SIP flows, scheme counts) without needing to explain any inputs. There is no parameter schema to complement, so the description's clarity about what data is returned is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides AMFI mutual fund industry data including total AUM, SIP flows, scheme count by category. It uses specific verbs and lists concrete deliverables (Total AUM, SIP inflows, folios, scheme breakdown), making its purpose unmistakable. It also distinguishes itself from sibling tools like mutual_fund_nav by focusing on industry-level flows rather than individual fund NAVs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool should be used by noting that AMFI publishes data free compared to costly Morningstar Direct, and it lists the data types available. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or alternative tool references. The context is helpful but not prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the tool returns historical price data and lists parameter options, but does not disclose output structure, rate limits, authentication requirements, or potential side effects. The examples hint at data granularity but not the actual response format, leaving a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-sentence purpose, a compact parameter list, and two illustrative examples. No filler or redundant content, and the structure front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a historical data tool, the description adequately covers input semantics and valid values, with examples for clarity. It omits details about the output data structure, but since an output schema exists, the description does not need to explain return values. Overall, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only parameter names and defaults with no descriptions (0% schema coverage). The description compensates fully by explaining each parameter: 'symbol' with ticker examples, and listing all valid values for 'period' and 'interval'. This enables the agent to select correct parameter values without ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Get historical cryptocurrency price data' which clearly identifies the action (get historical data) and the resource (cryptocurrency prices). This distinguishes it from sibling tools like crypto_price (current price) and stock_historical (stock 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical crypto data retrieval but does not explicitly state when to prefer this tool over alternatives like crypto_price or stock_historical, nor does it mention exclusions. The examples clarify how to use it but provide no explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It does not mention data freshness, rate limits, read-only nature, or any prerequisites/limitations. The listed 'Provides' items are more about output components than behavioral characteristics such as side effects or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear title, a bulleted feature list, an Args section, and examples. It is front-loaded with purpose. The Sensibull marketing sentence is somewhat extraneous for an AI agent, but it does not detract significantly from overall clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description adequately covers inputs and expected outputs. It lacks behavioral context (e.g., when to use vs alternatives) but is sufficient for a single-parameter tool with examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the symbol parameter, but the description's 'Args' section defines it as 'NSE stock or index symbol' and gives concrete examples. This adds meaning beyond the raw schema, though it doesn't address edge cases like case sensitivity or exact symbol formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Advanced options OI analytics' and enumerates its key outputs: Max Pain, PCR trend, IV summary, top OI strikes. This distinguishes it from sibling tools like nifty_pcr_trend or nse_options_chain by offering a broader analytical package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear examples (NIFTY, RELIANCE, BANKNIFTY) and specifies it works for NSE stocks and indices. However, it does not explicitly mention when to prefer this tool over alternatives like nifty_pcr_trend or options_greeks, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output type (links to documents) and parameter behavior (defaults, max count, filing type meanings), but does not mention error handling, rate limits, or authentication needs. It adds meaningful context but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line summary, a line about output, a structured Args section with bullet points, and three clear examples. No redundant information; every sentence contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and the tool's simplicity, the description adequately covers parameters, output type, and usage examples. The only notable gap is the lack of usage alternatives, but that is covered under Usage Guidelines. Overall, it provides sufficient context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), and the description fully compensates by explaining each parameter: symbol format with examples, filing_type options with meanings, and count with default and max. Examples further illustrate valid combinations, far exceeding schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get SEC filings for a US-listed company' and specifies it 'Returns links to actual filing documents on SEC EDGAR,' which defines the verb, resource, and scope. It doesn't explicitly differentiate from the sibling 'sec_filing_search', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied via examples (e.g., getting annual reports for AAPL), but there's no explicit guidance on when to use this tool versus alternatives like sec_filing_search, nor any exclusions or prerequisites. This is implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explicitly lists what the tool returns (full history up to 60 entries, annual totals, trailing yield, total dividends), but it does not mention potential errors, data source reliability, rate limits, or any side effects. The tool is clearly a read operation but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a rationale note, a bullet list of outputs, argument details, and examples. The Bloomberg/FactSet note is slightly extraneous but still relevant; otherwise every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, return values, parameter format, and examples. An output schema exists, so detailed return structures are not needed. It could be more complete with notes on error handling or invalid symbols, but for a single-parameter data retrieval tool it is quite thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for 'symbol', but the description fully compensates by explaining it as 'NSE or global stock symbol' and providing examples (RELIANCE, TCS, INFY, AAPL). This gives the agent exactly the information needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '10-year dividend history with yield calculation and annual summary' and lists specific outputs including full dividend history, annual totals, trailing yield, and total dividends. This differentiates it from sibling tools like 'dividend_history' by emphasizing the 'deep' 10-year scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that Bloomberg and FactSet charge for deep dividend history while yfinance is free, and the name 'deep' implies longer history, but it does not explicitly compare with the sibling 'dividend_history' tool. No clear guidance on when to choose this versus the simpler alternative is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return fields (current rate, change, high/low, 52-week range) which helps, but it does not mention data latency, error conditions, or rate limits. The description is adequate for a simple read tool 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose, a short line on return values, an Args section, and multiple examples. Every sentence is informative and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description adequately covers purpose, parameters, and return values. It has an output schema (not shown but present) that likely details return structure, so the description need not. However, it lacks any note on error handling or unsupported currency codes, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 does so via an 'Args' section and examples (e.g., 'from_currency: Source currency code (e.g., USD, EUR, GBP, AED, JPY)'). This adds clear meaning beyond the bare schema, but could be improved with validation rules or a more formal spec.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get live forex exchange rate between two currencies' with a specific verb and resource. It also lists the return values (current rate, day's change, high/low, 52-week range), which distinguishes it from sibling tools like stock_quote or crypto_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for forex conversion and provides examples of common pairs, but it does not explicitly state when to use this tool versus alternatives (e.g., crypto_price, stock_quote). No exclusions or explicit alternative references are given, so it falls at 'implied usage'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool is read-only (returns data), lists the content returned, and explicitly states the available years (a limitation). It does not add deeper behavioral context such as data source, update frequency, or potential errors, but for a simple historical data lookup it provides adequate transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise, using short paragraphs to state purpose, return content, available years, and argument format. Every sentence earns its place; no fluff or repetition. The front-loaded purpose sentence immediately clarifies the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and an output schema, so the description covers the essentials: what it does, what it returns, valid inputs. It even lists available years to set user expectations. Minor gaps include not describing the output structure or any prerequisites, but the output schema likely covers that, making it contextually complete for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a 'year' parameter with no description (0% coverage), so the description compensates well by explaining 'Budget year as string' and providing explicit examples ('2025', '2024', '2023') plus the list of available years. This adds meaningful guidance beyond the schema's type/default, though it could be even more explicit about validation constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Historical Union Budget impact by year' with a specific verb 'Returns' and content details (key announcements, sector winners/losers, market reaction). It distinguishes itself from sibling tools by emphasizing 'Historical' and 'past Indian Union Budgets', unlike the live-focused analyze_budget_live.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving past budget impact by year and lists available years, providing clear context. However, it does not explicitly mention when to use this tool versus alternatives such as analyze_budget_live, nor does it state exclusions or alternative tools. Guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the output fields and that no arguments are needed, implying a read-only operation. However, it does not specify data recency, potential latency, or failure behavior, which is a minor gap for a zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a concrete example. Every sentence adds value: what the tool does, what data it returns, and how to invoke it. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero parameters and the presence of an output schema, the description covers the core usage well. It lists the output fields and gives an example. A minor gap is not specifying the time range for 'upcoming and recent,' but this is not critical for a simple calendar tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description explicitly states 'No arguments needed' and the example reinforces that, adding clarity beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves upcoming and recent IPOs on NSE, with specific details like company name, price band, dates, issue size, and status. This distinguishes it from other calendar or market data tools, even without naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the resource (NSE IPOs) and includes a usage example, but does not explicitly say when to use it over sibling tools like earnings_calendar or nse_quarterly_results. Context implies it's for IPO event data, but no alternatives are mentioned or ruled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It details the input format and expected outputs, but does not explicitly state that it is read-only, mention authentication requirements, or note limitations. The examples add some context, but not comprehensive 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise purpose line, a brief explanation, an Args section, and examples. Every sentence adds value, and the format 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter is thoroughly documented, an output schema exists, and the purpose is clearly explained, the description is sufficient for an agent to select and invoke the tool correctly. The additional listing of outputs and examples further enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'holdings' as a string with zero description coverage. The description fully compensates by specifying the exact JSON structure, required fields (symbol, quantity, buy_price), and providing two clear examples. This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a stock portfolio, listing specific outputs (P&L, weights, risk). It uses a specific verb+resource but does not differentiate from the sibling tool 'analyze_portfolio' which likely has a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'Provide your holdings and get...' and includes examples, but it does not explicitly state when to use this tool over alternatives like analyze_portfolio or provide exclusions. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It lists the type of data returned and notes the tool is free, but does not mention error handling, data freshness, or explicitly state read-only behavior. This is adequate but not comprehensive for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, bulleted list, args section, and examples. It is slightly longer than strictly necessary due to the marketing line about paid features, but remains organized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, existing output schema), the description adequately covers the expected output categories and usage via examples. Minor gaps include data sources and error behavior, but these are not critical for this straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the symbol parameter with format and examples (e.g., RELIANCE, TCS, INFY, HDFCBANK), fully compensating for the schema's 0% description coverage. This goes beyond the bare schema definition, making the parameter unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a shareholding pattern breakdown for NSE stocks, listing specific categories (promoter, FII, DII, public). This distinguishes it from siblings like promoter_pledge and nse_fii_dii_data by covering all holder types, not just one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through examples and the context 'Who owns Reliance and how much', but it does not explicitly compare to alternatives or state when to prefer this tool. The line about covering paid features hints at value but lacks direct guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool uses historical price action and identifies specific levels, but it does not mention data sources, latency, limitations, or the exact structure of the returned output. The '[PRO]' marker is unexplained, leaving an ambiguity about access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, a detail sentence, a compact Args section, and two relevant examples. No redundant information or filler words are present; every line contributes to understanding how to call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core aspects: purpose, parameters, and usage examples. An output schema exists, so the lack of explicit return-value documentation is acceptable. However, it omits any note on data limitations, update frequency, or how the 'key price levels' are derived beyond stating historical price action, which keeps it slightly short of a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema fields lack descriptions. The description compensates by explaining both parameters: 'symbol' with example tickers and 'period' with allowed values and a default. This adds practical meaning beyond the bare schema, though it could include more details like the interpretation of 'period' values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Compute support and resistance levels for a stock,' which clearly states the action and resource. It further specifies that it calculates pivot points (R1, R2, R3, S1, S2, S3) and identifies key price levels, distinguishing it from generic technical analysis or other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its examples and the nature of the tool, but it does not explicitly state when to choose this tool over alternatives like technical_indicators or stock_historical. No exclusionary or comparative guidance is provided, relying instead on the agent's inference from the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure. It explains the scanning logic (volume spike > 3x, price surge > 20%, multiple circuit days) and the return structure (pump_probability, red_flags, verdict + recommendation). However, it omits details about data sources, error cases, or how the probability is computed, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections for scan patterns, returns, and arguments. The inclusion of the quoted statistic ('9 out of 10 times') adds illustrative flair but is not essential to tool operation, making it slightly less concise than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no annotations, output schema exists), the description covers purpose, detection logic, outputs, and parameter meaning. It does not address edge cases or potential errors, but that is acceptable for a straightforward analysis tool with a well-defined output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the only parameter: 'symbol: NSE symbol (most useful for small/micro caps)'. This adds meaningful context about the expected value and the target market segment, though it does not provide example symbol formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Detect pump-and-dump operator activity in an NSE stock', which is a specific verb+resource statement. It further distinguishes itself by listing concrete pump patterns (volume spike, price surge, circuit days) that are unique compared to sibling tools like detect_unusual_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by noting the tool is 'most useful for small/micro caps' and includes a realistic scenario ('This microcap hit 3 upper circuits in a week'). It does not explicitly name alternatives or when not to use it, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses supported interval options and default values, which is useful, but does not mention authentication, rate limits, pagination, or data ordering. Lacks deeper 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: one purpose line, interval list, and args explanation. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with an output schema, the description covers purpose, intervals, and parameters. Could add a note about NSE-only symbols or data ordering, but overall adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides clear semantics for all three parameters: symbol example, interval options list, days meaning and defaults. This fully compensates for the absence of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Historical OHLCV candles from Fyers API v3' – specific verb (get historical) + resource (OHLCV candles) + source (Fyers). Distinguishes from sibling candle tools like icici_candles or stock_historical by naming the source API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for Fyers data but does not explicitly mention alternatives or when not to use. There are many sibling historical/candle tools, and no comparison is given, so the agent must infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool aggregates data from 50 channels, offers a curated offline database, and supports optional live tracking via Telethon setup. It reveals dependencies (pip install, API credentials) and the comparison dimensions. While it doesn't mention data freshness or error handling, the provided behavioral depth exceeds a bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose, including a marketing quote ('I tracked 50 Indian stock tip channels for 30 days — here's which ones are scamming you') that adds no functional value. However, the structure is organized with a clear purpose statement, setup notes, and an Args section, making it navigable despite the extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, output schema present), and the description covers key aspects: what it compares, the channel input, the curated database, and live tracking prerequisites. It doesn't mention invalid channel handling or output format, but these are partially covered by the output schema and overall simplicity. The description is sufficiently complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `channel` is fully explained in the description: it gives an example handle ('@NSEBSEtips') and clarifies that leaving it empty returns the full comparison database. Since the schema has no per-property description (0% coverage), the description fully compensates with valuable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Dalal Street Telegram signal tracker' that compares 50 public Indian stock tip channels by accuracy, return, and pump-and-dump probability. This specific verb and resource, combined with its unique focus on Telegram social signals, distinguishes it well from the many market-data sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Works out of the box' and explains the channel parameter ('Leave empty for full comparison database'). However, it does not explicitly state when to prefer this tool over alternatives or provide exclusion criteria. The setup instructions for live tracking add context but do not fully guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the data is real-time, exchange-licensed, requires configuration, and lists the exact output fields (top 5 bids/asks, total queue sizes). It also notes the credential stays local. While it doesn't discuss failure modes or rate limits, it provides substantial behavioral context beyond a generic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bolded header, clear bullet points for outputs, and an example. It includes useful cost/licensing context that is not redundant. Slightly verbose, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema present (though not shown here), the description covers purpose, parameter format, configuration requirement, and output fields. It is complete enough for an agent to invoke the tool correctly, though it lacks error-handling or fallback guidance if configuration is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbol' with no description, so the description compensates by specifying it as an NSE symbol and providing concrete examples (RELIANCE, TCS, HDFCBANK). This adds meaningful guidance for a single parameter, though it could clarify whether exchange suffixes are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: 'Level 2 order book depth — top 5 bid/ask prices and quantities.' This clearly distinguishes it from sibling tools like stock_quote or nse_quote, which provide price snapshots rather than order book depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions prerequisites ('Requires Angel One API credentials') and that it provides live data 'when configured', giving some context. However, it does not explicitly state when to use this over alternatives or mention any exclusions (e.g., 'for a simple quote use stock_quote'), so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It correctly implies a read-only getter and adds useful interpretive context about FII/DII net buys being bullish/bearish signals. However, it does not mention data source, potential lag, whether DII values are provisional, or other operational caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main action, and every sentence contributes value: what it gets, what it shows, how to interpret it, and how to call it. The example and no-arguments note are useful, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument tool, the description thoroughly covers purpose, scope (today), interpretation, and usage example. Since an output schema exists, return-value details do not need to be repeated in the description, making it complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 reinforces this by explicitly stating 'No arguments needed' and providing a concrete example call (nse_fii_dii_data()), which adds clarity beyond the already-empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get FII (Foreign Institutional Investor) and DII (Domestic Institutional Investor) activity data.' It further defines what the tool does by stating it shows how much institutions bought/sold today, which clearly distinguishes it from broad market-data tools like nifty_index or stock_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool through phrases like 'today's FII/DII activity' and interpretive signals ('FII net buy = bullish signal'), but it never explicitly names alternatives or provides when-not-to-use guidance. While the context is clear, it lacks the exclusions and alternative comparisons needed for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It explains what data is returned and parameter behavior (days default 90, max ~365), but does not mention data freshness, rate limits, or any side effects. The note about being free is context but not a 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence, bullet points, and usage examples. The first sentence is front-loaded and the examples are helpful. The marketing comparison to Trendlyne/Screener Pro adds value but is slightly extraneous for tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, 1 required), an output schema, and the description's comprehensive examples and output summary, it is complete for an agent to select and invoke correctly. No further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides thorough parameter explanations beyond the schema: symbol examples (RELIANCE, TCS, INFY, HDFCBANK) and days lookback details (default 90, max ~365). Since schema description coverage is 0%, this fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'NSE insider trading and SAST disclosures for a stock.' It enumerates specific outputs (SEBI-mandated disclosures, buy vs sell counts, sentiment summary, acquirer/seller details) and distinguishes it from other NSE tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving insider trading data for a given symbol, with examples like nse_insider_trading('RELIANCE'). However, it does not explicitly state when to use this tool over alternatives like get_insider_signal or promoter_shareholding, and there are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes return content and the risk signal logic, and examples clarify expected behavior. However, it does not explicitly state that this is a read-only query, nor does it disclose potential error behaviors (e.g., invalid symbol handling) or data availability limits. The description is transparent about what data comes back but could be more explicit 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose. It uses bullet points for provided data, a clear Args section, and examples. Every sentence earns its place, covering rationale, risk interpretation, and usage without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is nearly complete. It explains why the data matters, what the risk signal means, and what outputs to expect. The only gaps are edge cases like unavailable data or invalid symbols, but these are minor for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'symbol' with zero description coverage. The description compensates fully by defining it as 'NSE stock symbol (e.g., RELIANCE, TCS, ADANIENT)' and providing two usage examples. This adds meaningful context beyond the raw schema and demonstrates correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Promoter pledge percentage — how much of promoter holding is pledged as loan collateral.' This is a specific verb+resource combination. It also lists exact outputs (promoter pledge % of total shares, pledge % of promoter holding, risk signal, quarter-wise breakdown) and distinguishes from sibling tools like promoter_shareholding by focusing specifically on pledge data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when checking pledge risk for a stock) and adds context about NSE publishing the data free vs Screener.in Pro. However, it does not explicitly compare to alternatives like get_pledge_alert or scan_pledge_risks, nor does it state exclusions for when not to use it. Usage guidance is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it detects mentions of specific sectors and returns instant mappings, and accepts partial text. However, it does not explain what happens on no matches, potential limitations, or the exact structure of the output, though the output schema exists to help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, usage instructions, an illustrative example, a list of detected topics, and an Args section. Every sentence adds value, and the example clarifies the expected mapping, making the description concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 nested objects) and the presence of an output schema, the description covers the essential usage well. It explains when and how to use it and what it returns. Missing are edge-case behaviors like handling of unrecognized text, but these are minor for a niche tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'text' parameter, but the description compensates by explaining it as 'Budget speech transcript text (paste directly from live broadcast)' with usage instructions. This adds clear meaning beyond the bare schema, making it easy for an agent to know what to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a real-time budget speech analyzer that maps speech text to sector/stock impact. It uses a specific verb ('analyze') and identifies the resource (budget speech) and output (sector + stock impact), distinguishing it from sibling tools like get_budget_impact which may serve a different function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'use on Feb 1st as FM speaks' and instructs to paste the speech text, including partial text. It does not explicitly discuss when not to use it or mention alternatives, but the real-time/live framing implies a clear trigger for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it is a manual trigger, that it operates on pending signals with elapsed windows, and that it returns a count of updated signals. However, it does not explain potential side effects, irreversibility, or idempotency. The core behavior is clear, but depth is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the main action, the second provides context, the third gives the trigger condition, and the fourth states the return value. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an output schema, the description covers the purpose, trigger condition, and return value. It is sufficiently complete for its simplicity. It could mention handling of signals that don't meet the window, but that is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is 100% (empty schema). The description does not need to explain parameters. Per the rubric, 0 params baseline is 4, and nothing reduces it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb and resource: 'Manually trigger outcome checking for all pending signals.' This unambiguously distinguishes it from sibling tools that handle quotes, analytics, or signal generation. The additional note about it normally running automatically clarifies its role as a manual override.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool: 'you can call this to force-check any signals whose 7-day or 30-day window has elapsed.' This provides clear context for invocation, though it does not name specific alternatives or state when not to use it. The guidance is present but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lists the returned fields and shows read-only intent via 'Get', but lacks explicit statements about data source, delay, or any limitations. This is adequate but not highly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into Returns, Args, and Examples sections, making it easy to scan. The Args section is slightly redundant with the schema, but the examples add value. Overall, it is efficient without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers purpose, input, and return fields sufficiently. It could mention data source or coverage limitations, but these are not critical for a simple overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'symbol' is thoroughly explained with a clear definition and multiple examples including both Indian (RELIANCE, TCS) and US (AAPL, MSFT) tickers. This fully compensates for the schema's 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get company overview and profile information' and enumerates specific return fields (name, sector, industry, market cap, etc.). This distinguishes it from related tools like stock_quote or income_statement. Examples reinforce the intended use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples provide clear context for when to use this tool (e.g., 'What does Reliance Industries do?', 'Tesla company overview'), implying use for fundamental company overview queries. However, it does not explicitly mention when NOT to use it or alternatives for pricing or financial statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by detailing the four signal sources, the alert levels (high/moderate/low/none), providing an example output, and listing the exact return JSON fields (alert_level, verdict, alerts, findings). However, it does not disclose potential limitations or data freshness, which would have made it fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, signals, return format, example, and args. It is front-loaded with the core purpose and uses bullet points for readability. Although it is somewhat lengthy (about 200 words), each section contributes value and the example output helps illustrate behavior without being superfluous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (4 signal categories, multiple output fields) and has an output schema, which reduces the burden on the description. The description nevertheless covers all the important aspects: what signals are scanned, the alert levels, a concrete example, and the return JSON structure. It does not mention data limitations or prerequisites, but it is sufficiently complete for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare 'symbol' string with no description. The description compensates fully by including an Args section that explains the parameter: 'symbol: NSE stock symbol (e.g. RELIANCE, HDFC, TATAMOTORS).' This clarifies the expected format and provides concrete examples, which is essential for correct invocation. Given the 0% schema coverage, this is a strong compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Detect smart money and unusual activity for any NSE stock.' It specifically enumerates the four signal categories (volume anomaly, options OI, block/bulk deals, promoter change), distinguishing it from sibling tools that focus on individual signals like options_oi_analytics or nse_bulk_deals. This makes the tool's role and scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is a combined multi-signal scanner, but it does not explicitly state when to use it versus more specialized alternatives. No when-not-to-use guidance or alternative tool references are provided. For instance, it does not say 'for only OI analysis, use options_oi_analytics.' The usage context is implied but not directly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the core behavior (returns upcoming earnings dates and estimates) but lacks explicit safety notes, data source, or limitations. It is not misleading but does not go beyond the obvious read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, output summary, args section, and examples. It is compact with no fluff, each sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description adequately covers purpose, output, and argument usage. It could mention error handling or timezone, but it is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains the only parameter 'symbol' with examples and states it is required, adding meaning beyond the bare schema (which has 0% description coverage). Minor caveat: the schema marks symbol as optional via default, but the description's explicit required guidance is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb + resource ('Get upcoming earnings dates') and clearly states it shows expected report date with analyst estimates. It distinguishes from siblings like predict_earnings by focusing on calendar/date info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use (when querying a stock's earnings date and estimates) through examples, though it does not explicitly list exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description discloses its core behavior: it flags specific categories of unusual resolutions (debt issuance, salary hikes, related-party transactions, etc.), which is substantial behavioral context. However, it does not explicitly state that the operation is read-only or mention any limitations or data source caveats, though the 'AI briefing' label and NSE source are implicitly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with the purpose, lists flags in a clear bullet-style format, includes a relatable example, and closes with the Args section. It is somewhat verbose and includes a rhetorical question that could be trimmed, but every section contributes to understanding, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, an output schema present, and a description covering purpose, flags, and parameter format, the tool is effectively complete for selection and invocation. The only gaps are the lack of explicit usage restrictions (e.g., unsupported exchanges) and no mention of output shape, but the existing output schema covers the latter, so the description is nearly exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly defines the 'symbol' parameter as an NSE symbol with concrete examples (RELIANCE, ZEEL, ADANIENT), far exceeding the schema's bare type string. This fully compensates for the schema's lack of description and gives the agent clear guidance on what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an AI briefing on AGM/EGM resolutions from NSE filings, which is a specific verb+resource. It distinguishes itself from sibling tools like get_stock_brief or get_morning_brief by focusing on unusual resolution flags, and the list of flagged items makes the purpose concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when assessing upcoming shareholder meeting risk (e.g., the example question about a debt raise), but it does not explicitly state when to use this tool versus alternatives or when not to use it. There is no mention of exclusions or conditions like symbol availability or market coverage, so it remains at implied-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and provides useful context: data source (public SEBI SAST disclosures), tracked transaction types (promoter/director/KMP), and detailed return fields (signal, net_signal, transactions, price change). It stops short of disclosing limitations like update frequency or historical depth, but is transparent for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a clear purpose, then uses a 'Returns:' list and an 'Args:' section for structure. The example quote adds flavor but is not strictly necessary; still, the overall length is reasonable and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects for a simple one-parameter tool: what it does, data source, outputs, and parameter format. An output schema exists, so return values don't need to be re-explained. It is complete enough, though it could benefit from explicitly differentiating when to use this over closely related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' as a string with no description. The description compensates completely by specifying 'NSE symbol' and providing concrete examples (RELIANCE, INFY, ZEEL). This bridges the 0% schema_description_coverage effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Insider trading pattern analysis from SEBI SAST disclosures (public).' It specifies the resource (insider trading data) and the action (pattern analysis, returning a signal). It distinguishes from siblings like nse_insider_trading by focusing on derived conviction signals (BUY/SELL/NEUTRAL) rather than raw disclosures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when assessing insider conviction, e.g., 'Insiders buying their own stock = strongest possible conviction signal') but does not explicitly compare to alternatives like nse_insider_trading or promoter_shareholding. There are no exclusion statements or direct references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the data source (public AMFI portfolio disclosures), lists the return fields including 'verdict + risk level', and implies limitations by listing supported funds. It does not detail error handling or data freshness, but the key behavioral aspects are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for supported funds, returns, and args. It is longer than the bare minimum but every part adds value; the motivating quote is slightly extraneous but reinforces purpose. Overall it is efficient and front-loaded with a clear summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers the essential context: data source, supported funds, and detailed return structure. It does not mention edge cases like unsupported fund name formats or portfolio disclosure lag, but given the output schema exists and the tool's simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (coverage 0%), but the description compensates by explaining both fund1 and fund2 with examples ('HDFC Flexi Cap'), and further clarifies by naming the supported fund list. This fully conveys parameter meaning and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Mutual fund overlap analyzer using public AMFI portfolio disclosures,' giving a specific verb (analyzer) and resource (mutual fund overlap). This clearly distinguishes it from sibling tools like mutual_fund_nav or amfi_fund_flows by focusing on overlap comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The example quote illustrates a common use case (assessing diversification between two funds) but does not explicitly state when to use this tool over alternatives. There is no mention of exclusions or when-not-to-use, so usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral disclosure. It does explicitly say it 'compiles in one call' and enumerates the output contents, giving the agent a sense of what to expect. However, it omits any caveats about data freshness, pre-market timing dependencies, latency, or error behavior, which would be valuable for a tool that aggregates multiple market data points.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact lead sentence followed by a five-item bulleted list. Each bullet identifies a distinct component, and there is no filler, redundancy, or unnecessary technical detail. It is easy to scan and front-loads the key 'morning F&O brief' concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter aggregation tool, the description is sufficiently complete: it names the target audience, the time, and the five data elements it returns. The presence of an output schema covers detailed return structure, so the description need not enumerate every field. The only minor gap is not specifying whether the brief is for the current trading day or any dependency on market open data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly focuses on the output content rather than parameter fields. The schema coverage is trivially 100% with no properties, and the description adds value by specifying what the returned brief contains, which is the primary semantic information an agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an 8:15 AM F&O-focused morning brief for NIFTY and BANKNIFTY traders and lists the exact components it compiles (GIFT Nifty, India VIX, direction probability, options setups, morning_text). This distinguishes it from general briefs like get_morning_brief and other single-purpose market data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: intended for NIFTY and BANKNIFTY F&O traders, intended for 8:15 AM use, and it produces a ready-to-send morning_text for messaging platforms. It does not explicitly contrast with sibling tools like get_nifty_outlook or get_morning_brief, nor does it state when not to use it, but the implied use case is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool fetches and classifies orders, and adds predictive context about severity preceding corrections. However, it omits operational details such as data freshness, output structure, or limitations, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, followed by a practical example and parameter documentation. The illustrative quote is slightly extra but adds context without bloating the description. Overall, it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema (not shown), the description adequately covers the purpose and parameter usage. It lacks details about update frequency or data source, but these are not critical given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), but the description comprehensively explains the 'sector' parameter with concrete examples ('Banking', 'SME/Micro', 'Broking') and the use of 'all' for a full report. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches recent SEBI orders and classifies them by severity and sector, with a specific verb ('Fetches') and resource ('SEBI orders'). It differentiates from sibling tools like sec_filing (SEC) by focusing on SEBI enforcement order tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description frames the tool as an 'early warning before regulatory crash' and mentions historical impact on stock corrections, providing clear context for when to use it. However, it does not explicitly exclude alternatives or name sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses the output structure and data source (real Indian market data), but does not mention read-only safety, latency, data freshness, or any side effects. This is adequate for a getter tool, but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for the six personas and output sections. It is somewhat embellished with the 'Rs500Cr fund meeting' analogy, but the core content is efficient and earns its place. A small reduction for the non-essential metaphor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one param) and no annotations, the description provides a detailed account of the output structure and the analysis methodology. It covers the input parameter sufficiently and outlines return keys. It lacks any limitations or prerequisites, but overall it is complete enough 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare 'symbol' property with 0% description coverage. The description fully compensates by stating 'symbol: NSE stock symbol (e.g. RELIANCE, TCS, HDFCBANK)', giving source, type, and concrete examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Multi-agent AI stock brief: 6 personas debate whether to BUY, HOLD, or SELL' and details the six analytical perspectives. It clearly distinguishes this from sibling tools like stock_quote or technical_indicators by describing a consensus-based multi-agent output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to get a comprehensive consensus on an NSE stock from multiple expert personas. It does not explicitly state alternatives or exclusions, but the context is strong enough to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the tool returns current VIX, signal classification (low/elevated/panic), 30-day statistics, full history, and an interpretation guide. It also explains the free NSE data source. It doesn't detail response format or data delays, but for a read-only market data tool this is substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear title, rationale, bullet-point feature list, parameter explanation, and examples. It is slightly verbose (e.g., the Trendlyne note) but every section adds useful context and no information is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the purpose, parameter, and examples. It lacks explicit caveats about data availability or error scenarios, but the provided details are sufficient for most use cases and the output schema handles return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter coverage, but the description fully compensates by defining 'days' as the lookback period with a default of 30 and providing usage examples for both default and custom values. This makes the parameter entirely unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the India VIX volatility index, listing its specific outputs: current level, daily change, signal zones, 30-day stats, full history, and interpretation guide. This distinguishes it from siblings like nifty_index or stock_quote by naming the exact instrument and core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching India VIX data but does not explicitly state when to use this tool versus alternatives like nifty_index or nse_historical. The note about Trendlyne vs NSE data source provides context but not direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses the behavioral trait that results are 'sorted by risk level (critical first)' and that scanning is simultaneous, but it does not detail output fields, error handling, or any potential limitations. A 3 is appropriate given the partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus an args note. It front-loads the core purpose, then adds valuable context and parameter details. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity (one parameter) and the presence of an output schema, the description is largely complete. It covers purpose, use case, and parameter semantics. Minor gaps remain regarding interpretation of risk levels or batch limit restrictions, but these are not critical for a scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'Args' section explicitly defines 'symbols' as 'list of NSE symbols' with concrete examples, adding meaning beyond the bare schema. This fully bridges the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Scan multiple NSE stocks for promoter pledge risk simultaneously') with a specific resource and scope. It distinguishes itself from the sibling 'promoter_pledge' tool by emphasizing multi-stock scanning, 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case: 'Useful for screening your watchlist or Nifty 500 for pledge dangers.' This implies batch screening over single-stock queries, but it does not explicitly mention alternatives or when not to use the tool, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden. It discloses that it returns OHLCV data with summary stats, which is useful. However, it does not mention potential caveats like rate limits, data availability for certain exchanges, or that intraday intervals may be limited by period (e.g., 1m data only available for recent periods). This is a moderate disclosure, neither rich nor misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a return type line, Args with enumerated options, and two clear examples. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return format doesn't need explanation. The description covers purpose, parameters, and examples. It lacks explicit notes on parameter constraints (e.g., 1m interval only for short periods), but for a straightforward historical data tool it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning parameter descriptions are absent. The tool description compensates by explicitly listing valid period and interval values, and providing examples that map symbols to real companies. This gives the agent essential semantic context beyond raw schema, though it doesn't detail output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get historical price data for any global stock' with a specific verb and resource. It distinguishes itself from siblings like stock_quote (current price) and crypto_historical (crypto-specific) by specifying 'global stock'. The Args and Examples further clarify what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical price data retrieval, with examples showing typical calls. However, it doesn't explicitly contrast with alternatives like stock_quote for current prices or technical_indicators for derived metrics. The context is clear enough for an agent to select this tool when historical OHLCV data is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It states 'real-time' and lists returned fields, but doesn't mention data source, latency, error behavior for invalid symbols, or any limitations like delayed quotes for certain markets. This leaves the agent uncertain about edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, market coverage, returns list, and Args/Examples sections. It's slightly verbose due to repetition of region lists, but every sentence adds practical value, especially the symbol format examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the essential knowledge: what it does, which symbols to use, and a relevant cross-reference to nse_quote. It lacks mention of limitations or when to prefer other real-time quote tools, which prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by detailing symbol formats for US, UK, Japan, Hong Kong, and India, with concrete examples such as HSBA.L, 7203.T, and RELIANCE.NS. This goes far beyond the bare 'symbol' parameter in the schema and is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Get real-time stock quote for any global stock.' It clearly distinguishes itself from siblings by emphasizing global coverage (US, UK, Europe, Asia, India) and explicitly points to nse_quote for Indian stocks, setting it apart from India-only quote tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: works for multiple regions and gives symbol format examples. It also directs users to nse_quote for Indian stocks, which is an explicit alternative. However, it doesn't compare against other similar quote tools like live_quote, fyers_live_quote, or icici_live_quote, so guidance for choosing between these is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It uses 'View' implying a read-only operation, and it describes the row contents (symbol, signal, price, 7-day return, outcome label). However, it does not disclose any potential side effects, required permissions, data freshness, or other behavioral traits beyond the basic reading of history. It adds some value 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-organized: a one-sentence purpose, a row-format overview, a usage line, and a clear Args block. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need to explain return values in detail, yet it does. It covers purpose, usage, and parameters adequately. Minor gaps like data recency or error behavior are not mentioned, but these are non-critical given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains both parameters: symbol as 'NSE symbol to filter (e.g. RELIANCE), or \'\' for all' and limit as 'number of rows to return (default 20, max 100)'. This adds meaning beyond the bare schema and even provides an example and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'View recent signals logged by FinStack with their actual outcomes', which clearly states the verb (View), resource (signals logged by FinStack), and the specific scope (recent, with actual outcomes). It distinguishes itself from siblings like get_signal_accuracy or check_signal_outcomes by emphasizing the historical listing of signals and their outcomes, not accuracy metrics or targeted checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'audit the model, build trust with users, or export for analysis.' This gives clear context for when to use the tool, but it does not explicitly mention alternatives or when not to use it, stopping short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states that the tool checks configuration status and provides token instructions, implying a read-only operation. However, it does not explicitly mention side effects, authentication requirements, or error behavior, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's purpose without filler words. It is concise and easy to parse, with every word contributing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool takes no parameters and an output schema exists, the description is sufficient for an agent to understand what the tool does and when to invoke it. It clearly names the broker API (ICICI Breeze) and the two key outputs (configuration status and token instructions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description adds context by specifying what the status check covers (configuration status and session token instructions), which helps the agent understand the tool's scope even though there are no parameter semantics to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'check' and clearly identifies the resource as 'ICICI Breeze API configuration status' with the added context of 'daily session token instructions.' This precisely distinguishes it from sibling tools like icici_live_quote or fyers_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when checking ICICI Breeze API configuration status or retrieving daily session token instructions. However, it does not explicitly mention alternative tools or exclusions, so it stops short of being fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral transparency. The description implies a read-only operation via 'Get' and lists the return fields, but it does not disclose data freshness, error handling, or any side effects. It is a functional description without additional behavioral caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, a list of return values, a clear Args section with bullet points, and examples. Every sentence earns its place; there is no fluff or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the essential aspects: what it does, what parameter to pass, and what is returned. Minor gaps include not mentioning the default index_name (NIFTY50) and lack of error-handling details, but these are not critical for a simple getter. Overall, it is complete enough 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a parameter description coverage of 0%, so the description must compensate. It does so thoroughly: it lists every valid index_name option with explanations, synonyms (e.g., NIFTY for NIFTY50), and even provides three examples showing expected usage. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current value of Indian market indices.' It specifies the resource (Indian market indices) and enumerates the exact indices (NIFTY50, SENSEX, BANKNIFTY, etc.), distinguishing it from sibling tools that focus on individual stocks (e.g., stock_quote, nse_quote).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for retrieving index values, but it does not explicitly mention alternatives or when not to use it. The context is unambiguous (e.g., options include ALL for all indices), but there are no exclusions or alternative tool references, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It discloses the scan modes and the threshold's effect, and examples hint at the expected output. However, it doesn't mention output format, pagination, or potential limitations, which are relevant for a scanner tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line purpose, a brief rationale paragraph, and bullet-point parameter documentation. It is slightly verbose with the popularity note, but every sentence contributes to understanding the tool. The layout is front-loaded and easy to follow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter scanner, the description comprehensively covers the tool's purpose, parameters, and usage in different scenarios. Since an output schema exists, the lack of return-value detail is not a gap. The description is sufficient for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema (0% description coverage) provides only types and defaults, so the description fully compensates by explaining both parameters in detail: the valid values for scan_type and the meaning of threshold_pct as a percentage. The examples further illustrate valid parameter combinations, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Scan') and resource ('Nifty 50 stocks near their 52-week high or low'). It distinguishes itself from siblings by focusing on 52-week extremes and even notes it's the most popular scan on Screener.in, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (momentum candidates near highs, value or falling knives near lows) and provides multiple examples of scan types and thresholds. However, it doesn't explicitly name alternative tools or specify when NOT to use this scan, so it falls short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the expected return values (OPEN, CLOSED, PRE_OPEN, POST_CLOSE), trading hours, and IST time, and explicitly states 'No arguments needed.' It does not mention update frequency or latency, but these are minor omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, followed by output details, argument requirement, and a concrete example. Every sentence contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is complete. It explains what the tool returns (market status, trading hours, IST time), states that it takes no arguments, and provides an example. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema already reflects that (empty properties). The description adds 'No arguments needed,' which confirms but doesn't extend the schema. Per the baseline for 0 parameters, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Check') and resource ('Indian stock market (NSE/BSE)'). It also lists possible return statuses, making the purpose unmistakable and distinct from sibling quote/analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (e.g., example 'Shows if market is open right now') but does not explicitly compare with alternatives or state when not to use it. However, for a simple no-arg status check, the purpose itself is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the returned data fields (strike price, premium, volume, OI, IV, PCR) and notes it is a [PRO] feature, but does not address error handling, rate limits, or explicitly confirm read-only behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a one-line summary, a list of returned fields, an args section, and examples. Every sentence adds value, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and presence of an output schema, the description covers the essential aspects: what the tool does, what data it returns, and how to call it. Minor details like expiry selection or pagination are not addressed, but they are not critical for the tool's core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description for the 'symbol' parameter, but the description fully compensates by explaining it accepts NSE stock or index symbols and gives three concrete examples (RELIANCE, NIFTY, BANKNIFTY). This is sufficient for unambiguous invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves options chain data for NSE stocks or indices, using a specific verb ('Get') and resource ('options chain'). This distinguishes it from siblings like options_oi_analytics or options_greeks, which focus on deeper analysis rather than raw chain data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through examples (RELIANCE, NIFTY, BANKNIFTY) and clearly indicates it is for getting options chain data. However, it does not explicitly mention when to use this tool versus alternatives or any exclusions, so it lacks explicit selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It details the return fields (price, change, volume, market cap, P/E ratio, 52-week range, sector) and notes 'and more,' but does not disclose data source delays, rate limits, or potential errors. The examples imply 'live' data, but the description itself is vague about data freshness. This is adequate for a simple quote tool but leaves some unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a main sentence, a list of return stats, a parameter explanation, and examples. Every sentence adds value without redundancy. It is appropriately sized for a single-parameter tool and front-loads the main functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple quote tool with one parameter, the description is largely complete. It covers input format and examples, and lists the return fields, which is helpful given no output schema is displayed. It does not cover edge cases like invalid symbols or availability of data, but these are not critical for a basic quote tool. Overall, it provides sufficient context for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage (the parameter property 'symbol' has no description). The description compensates fully by explaining the parameter: 'NSE stock symbol (e.g., RELIANCE, TCS, INFY, HDFCBANK, SBIN, ITC)' with multiple examples. This gives an agent clear guidance on what value to supply and the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get real-time NSE (National Stock Exchange) quote for an Indian stock.' It uses a specific verb (Get) and resource (NSE quote), and the examples (e.g., 'nse_quote("RELIANCE") → Reliance Industries live price & stats') reinforce the purpose. It distinguishes from siblings like bse_quote by explicitly targeting NSE.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: use when you need a real-time NSE quote for a specific Indian stock. It names the input format (NSE symbol) and provides examples. However, it does not explicitly differentiate from other quote tools in the sibling list (e.g., stock_quote, live_quote), so it lacks explicit exclusion or alternative guidance, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the default expiry behavior ('uses nearest if not provided') and that it returns both calls and puts. However, it omits data source details, latency, rate limits, or any prerequisites, and includes a promotional sentence that adds no behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence, a 'Provides' section, Args, and Examples. However, the marketing line ('Covers features Sensibull Pro charges ₹1,300/month for — free here.') is non-essential fluff, and the Greek definitions are somewhat verbose for an AI agent that likely already knows these terms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, both parameters, default behaviors, and includes usage examples. Since an output schema exists (though not shown), return value details are presumably handled. For a 2-parameter calculator with no annotations, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero descriptions, but the description fully compensates by defining `symbol` as an NSE stock or index symbol with concrete examples (NIFTY, RELIANCE, INFY) and `expiry` as an optional YYYY-MM-DD string with default behavior. Examples illustrate usage of both parameters in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Calculate Black-Scholes Greeks (Delta, Gamma, Theta, Vega, Rho) for all option strikes,' clearly stating the verb and resource. It also lists the specific Greeks and notes 'Full chain with Greeks for both calls and puts,' distinguishing it from OI-focused siblings like options_oi_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context through examples like `options_greeks("NIFTY")` and explicit parameter descriptions. However, it does not mention when to use this tool over alternatives such as `nse_options_chain` or `technical_indicators`, nor does it provide any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the basic purpose by detailing exactly what data is returned (the six rates, stance, and action summary) and notes the data source (free from RBI vs. expensive Bloomberg data). It does not mention freshness or error handling, but no annotations are needed for a read-only data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a bulleted list, and a usage example. The Bloomberg cost comparison is slightly tangential but brief and adds context. Overall, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description is complete: it names all included fields, provides an example, and explains the data source. It does not describe the exact output schema, but this is covered by the existing output schema structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so there is nothing for the description to explain. The example `rbi_policy_rates()` confirms no arguments are required. Baseline 4 for zero parameters applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Current RBI monetary policy rates' and enumerates the exact rates (Repo, Reverse Repo, CRR, SLR, MSF, Bank Rate) along with stance and last policy action. This leaves no ambiguity about the tool's purpose and distinguishes it from broader macro tools like india_macro_indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals when to use the tool—whenever current RBI policy rates are needed—and provides a concrete example. It does not explicitly exclude other tools or name alternatives, but given the specific subject matter, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return structure (ranked_watchlist, top_buys, top_risks) and mentions sorting by signal_score, but it doesn't clarify behavioral aspects like rate limits, data freshness, or whether the ranking is purely based on the multi-factor score without external filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with clear sections: a one-sentence purpose, a bulleted 'Best use' list, an args example, and a returns breakdown. Every line serves a purpose, and the main verb is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, existing output schema, and no annotations, the description provides sufficient operational context. It names expected outputs and typical usage scenarios. It slightly lacks detail on what signal_score represents or how thresholds for top_buys/top_risks are determined, but this is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining the only parameter: 'symbols: list of NSE symbols (e.g. ["RELIANCE", "TCS", ...])'. It adds important context including exchange (NSE) and a concrete example, making the parameter unambiguous despite the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Batch-rank a watchlist using FinStack's multi-factor stock signal score.' This clearly states what the tool does and distinguishes it from single-symbol tools like get_stock_signal_score by emphasizing batch capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Best use' section explicitly lists concrete scenarios: daily watchlist triage, n8n/WhatsApp automation, and finding top buys/risks in one shot. This provides clear context for when to use the tool, though it doesn't explicitly name alternatives to exclude.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns specific financial fields and explains the quarterly parameter's behavior. However, it does not explicitly state whether the operation is read-only or any side effects, though 'get' implies non-mutating. It gives useful context on outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, listed return fields, parameter documentation, and examples. Every sentence is useful, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters, and the description covers its purpose, parameters, examples, and output fields. An output schema exists for return values, so the description is complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the only source of parameter meaning. It thoroughly explains the 'symbol' parameter with examples (RELIANCE, TCS, AAPL, MSFT) and describes 'quarterly' with default behavior and example usage. This adds significant value beyond the schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Get balance sheet for a company.' This clearly distinguishes it from sibling financial statement tools like income_statement and cash_flow. Examples further reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a balance sheet is needed) and provides usage examples, but it does not explicitly differentiate from alternatives or state when not to use it. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data source (SEBI filings), scope (last 3-5 years), and categories (environment, social, governance). It adds context about the free vs paid data, but doesn't detail return format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately verbose but well-structured with a clear opening, bullet points, and examples. Some marketing context (Bloomberg/LSEG cost) is not strictly necessary for invocations, but it does not detract from usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. The description thoroughly covers the data scope, the source, and the parameter format. Missing explicit usage guidance, but the tool's niche purpose is well-defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the sole parameter clearly: 'symbol: NSE stock symbol' with examples (RELIANCE, TCS) and usage examples. This fully compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides BRSR ESG data for listed companies, listing specific content (filing links, framework, disclosures). It clearly distinguishes from siblings by addressing Indian BRSR/ESG, which no other tool covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: SEBI mandates BRSR for top 1000 Indian companies and this tool surfaces those free filings. It implies use for ESG/BRSR queries but doesn't explicitly compare with alternatives like sec_filing or company_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the real-time nature and the return fields (price, change, volume, market cap, key ratios). It does not mention limitations such as rate limits or invalid symbol handling, but the provided details go beyond a bare 'get quote' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a purpose sentence, a return-field sentence, one parameter definition, and two examples. It is front-loaded with the core purpose and contains no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter quote tool, the description covers purpose, return content, parameter semantics, and usage examples. Since an output schema is present (as per context), it need not describe the full return structure. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'symbol' parameter (0% coverage). The description compensates by defining it as a 'BSE stock symbol' and providing concrete examples (RELIANCE, TCS, INFY) plus usage examples that clarify the expected input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get real-time BSE (Bombay Stock Exchange) quote for an Indian stock' and lists return fields (current price, change, volume, market cap, key ratios). This specific verb+resource distinguishes it from siblings like nse_quote and live_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied via the BSE focus and examples, but there is no explicit guidance on when to use this tool over alternatives (e.g., nse_quote) or when not to use it. The description does not state exclusions or direct comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return fields and parameter behavior, which is useful, but it does not mention data sources, freshness, limitations, or error scenarios. Since it is a read-only 'get' tool, the transparency is adequate but not rich, warranting a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose, a brief list of return fields, an Args section, and examples. Every sentence is informative, no fluff, and the most critical info (purpose) is front-loaded. The format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, output schema present), and the description covers purpose, parameter semantics, return fields, and usage examples. The presence of an output schema means return values are fully documented elsewhere, so the description need not elaborate further. It is complete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does so excellently: symbol is clarified with ticker examples, and quarterly is explained with default behavior and a usage example. This adds substantial meaning beyond the bare schema property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get cash flow statement for a company' which is a specific verb+resource. It distinguishes from sibling tools like income_statement and balance_sheet by clearly naming the cash flow statement and listing the specific metrics returned (operating, investing, financing, FCF, capex).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, including examples and the annual/quarterly option. It does not explicitly mention alternatives or when not to use, but the purpose is self-evident among sibling financial statement tools, so it meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return fields and emphasizes the live nature of the data, but it omits details like data source, freshness, rate limits, or error behavior. For a simple read-only price tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose statement, a list of return metrics, an Args section, and clear call examples. Every part adds value; there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter), the presence of an output schema, and the provided examples, the description is complete. It tells the user what the tool does, what it returns, how to use it, and what symbols are acceptable. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbol' with 0% description coverage, and the description compensates fully with an Args section that explains symbol as a crypto ticker and provides concrete examples (BTC, ETH, SOL, XRP, etc.). This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states 'Get live cryptocurrency price in USD' and lists the exact metrics returned (current price, 24h change, market cap, volume, all-time high). This clearly distinguishes the tool from siblings like crypto_historical and stock_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: getting a live cryptocurrency quote. The examples demonstrate typical usage for BTC, ETH, and SOL. However, it does not explicitly mention alternatives or exclusions, such as 'for historical data use crypto_historical'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It enumerates the data categories included, which is useful, but does not mention potential limitations such as data freshness, error behavior, or performance. It neither contradicts annotations nor provides deep transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences and an arg list. Every sentence adds value—defining the tool's scope and purpose—without unnecessary fluff. The structured arg section is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, simple get operation) and the presence of an output schema, the description provides enough context: it lists the event types included and clarifies the tool's role. No additional explanation of return values is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully compensates by explaining both parameters: 'symbol' with NSE examples and 'max_events' as the max timeline events. This adds meaningful meaning beyond the schema's bare names and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool provides a 'unified stock timeline' covering news, results, insider, bulk deals, sentiment, pledge, and smart money. It also frames it as the 'what changed recently?' tool, clearly distinguishing it from sibling tools like get_stock_brief or get_social_sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage cue ('what changed recently?') that implies when to use this tool. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses the four input signals, the exact output fields (beat_probability_pct, signal, key_risks, what_to_watch, next_earnings_date), and mentions the 'AI earnings preview' nature. It doesn't discuss limitations or accuracy, but it is transparent about the inputs and outputs, which is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately lengthy but well-structured with bullet points for inputs, outputs, and an example use case. It is front-loaded with the core purpose and every section contributes value. The 'Viral use' sentence is slightly informal but still provides usage context, so it doesn't feel wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple signals, rich output), the description is comprehensive. It covers what the tool does, which signals are used, what it returns (with field names and examples), and the parameter. Even though an output schema exists, the description's return-type summary is useful and complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by documenting the single parameter: 'symbol: NSE symbol (e.g. TCS, INFY, HDFCBANK, RELIANCE)'. This adds examples and clarifies the expected format beyond the bare schema definition, which is helpful for an agent selecting the correct input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'AI earnings preview before quarterly results' that estimates beat/miss probability. It specifies a concrete action (predicting earnings) and a resource (upcoming quarterly reports), distinguishing it from sibling tools like nse_quarterly_results or earnings_calendar which report actuals or dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before quarterly results and gives a specific use case: 'post prediction before TCS/Infy results.' It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough that an agent would know to invoke it when an earnings preview is requested prior to results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses meaningful behavior: the API key stays in a local .env file, is never committed, and the code only reads environment variables. This adds value beyond a simple 'check status' by explaining data handling. While it doesn't state side effects or failure modes, for a read-only status tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear purpose sentence, a behavioral explanation, a security note, and an example. Every sentence earns its place without redundant phrasing. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description covers purpose, usage behavior, setup instructions, security context, and an example. It does not need to explain return values because the output schema exists. The description is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making schema coverage trivially 100%. The baseline for 0 parameters is 4, and the description adds no parameter-specific information because none is needed. No additional semantic enrichment is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Check Angel One SmartAPI integration status and get setup instructions,' naming a specific verb, resource, and broker. This distinguishes it from sibling tools like fyers_status and icici_status by explicitly focusing on Angel One. It is not a tautology and provides a precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it shows whether credentials are configured and explains setup instructions, giving an implied when-to-use. The example 'broker_setup_status() → Check if Angel One is connected + setup guide' reinforces the use case. However, it does not explicitly mention alternatives or exclusions, such as comparing with other broker status tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the data source, the fields returned, and the fact that it is free. It does not mention error handling, data freshness, or potential limitations, but for a simple read-only retrieval tool this is largely sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an introduction, bullet list of outputs, args, and examples. The Bloomberg pricing detail adds context but is not essential for tool invocation, making it slightly less concise than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description provides all necessary context: purpose, input format, examples, and output fields. It is complete enough for an agent to select and invoke the tool accurately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, symbol, is fully defined in the description as an NSE stock symbol with concrete examples. The input schema provides only the parameter name and type, so the description adds necessary context and usage syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool provides credit ratings for Indian listed companies from SEBI-mandated exchange filings. Lists specific data fields (agency, rating, action, instrument, outlook, filing date), which distinguishes it from all sibling tools focused on quotes, financials, and market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies input as NSE stock symbol and provides examples for RELIANCE and ADANIENT. The description implies use when credit rating information is needed, and the uniqueness of the tool among siblings removes ambiguity. It does not explicitly mention alternative tools 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It explains the data source (NSE public shareholding disclosures), the output structure (signal, confidence, interpretation), and the signal logic. The quarterly data lag is disclosed, providing a key behavioral trait. It does not mention rate limits or auth, but these are likely not critical for an analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections for purpose, signal logic, data source, arguments, and returns. It is front-loaded with the main goal, and the example quote is illustrative. It is not overly verbose; each section contributes to understanding, though it could be slightly trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, signal logic, data frequency, parameter format, and expected return fields. It explains the output includes divergence_type, signal, confidence, interpretation, historical implication, and raw QoQ data. This makes it highly complete given the single symbol argument and the analysis nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 'symbol' with no description, but the description explicitly explains 'symbol: NSE symbol (e.g. HDFCBANK, RELIANCE, TATAMOTORS)'. This fully compensates for the schema gap and adds practical examples, making parameter semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Detect FII vs retail divergence'. It defines the signal logic with clear buy/sell scenarios and a concrete example (HDFC Bank), distinguishing it from raw FII/DII data tools like nse_fii_dii_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when this signal is relevant: when FII and retail move in opposite directions. It also notes the data comes from quarterly NSE disclosures, implying trend-based usage. However, it does not explicitly mention when not to use it or list alternative tools, though the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does well by revealing the output format ('Returns structured JSON + morning_text') and the fact that it compiles multiple data points into a single call. It does not mention errors, caching, or data latency beyond the 'yesterday' reference, but for a read-only brief this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose statement followed by a clear bullet list of included components. Every bullet adds value and the whole is under 120 words. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description is remarkably complete. It enumerates all eight data categories included in the brief and describes the return format. Given the output schema exists to define the exact JSON structure, the description provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (trivially, as there are no parameters). Per the rubric, a zero-parameter tool receives a baseline of 4. The description adds no parameter-specific detail because none exists, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '8:15 AM pre-market brief for Indian traders.' It provides a specific verb ('compiles') and resource (pre-market brief), and lists eight concrete components (GIFT Nifty, India VIX, FII flows, etc.). This distinguishes it from most siblings, such as get_morning_fno_brief, by emphasizing a broader market brief.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: '8:15 AM pre-market brief' signals that this is intended for a specific time and purpose. It does not explicitly state when not to use it or name alternatives, but the clear pre-market framing gives adequate guidance for selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly explains what the tool returns (Nifty close/change, global indices, market status, links) and that it is free, which is useful context. It does not explicitly state read-only semantics, but the nature of a data retrieval tool is clear. It could add more about data freshness or limitations, but overall adequately discloses behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, bullet points for provided data, and a practical example. It is appropriately sized—concise yet informative—and front-loads the core purpose without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a 0-parameter tool with an output schema. It lists all provided data categories, includes an example invocation, and mentions the free-access advantage. Since an output schema exists, detailed return value descriptions are unnecessary. It provides enough context for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline score is 4 according to the rubric. The description does not need to explain parameter meanings since there are none. The example 'gift_nifty()' reinforces that no arguments are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'GIFT Nifty pre-market data + overnight global indices for Indian market preview.' It lists exact data components (Nifty 50 close, global indices, market status) and distinguishes itself from siblings by focusing on pre-market global sentiment and GIFT Nifty, which is not covered by sibling tools like nse_market_status or nifty_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for pre-market analysis with an example showing a call to get 'Pre-market global sentiment + Nifty reference.' It also notes this tool is a free alternative to Bloomberg, providing context on when to use it. However, it does not explicitly specify when not to use it or compare to alternatives like nse_market_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the market coverage, quarterly/annual behavior, and example data horizon ('last 4 years'). While it doesn't mention rate limits or explicit read-only confirmation, the 'Get' verb implies a safe read operation and the description adds meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, a bullet-like list of returns, an args section, and multiple examples. It is front-loaded with the primary purpose and every sentence contributes useful information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so detailed return structure is not required. The description covers purpose, parameters, usage examples, and market scope. Minor ambiguity remains about the exact number of periods returned (annual example mentions 4 years but quarterly does not specify), but overall it is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are entirely absent (0% coverage). The description fully explains both parameters: symbol with concrete ticker examples (RELIANCE, TCS, AAPL, MSFT) and quarterly with its True/False semantics. It also shows example invocations, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get income statement (Profit & Loss) for a company' and lists specific P&L line items (revenue, COGS, net income, EBITDA, etc.), distinguishing it from siblings like balance_sheet and cash_flow. It also mentions dual market coverage (India/US), further clarifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with examples for both annual and quarterly use cases, as well as Indian and US tickers. It explains the quarterly flag's effect but does not explicitly mention when to prefer this over sibling tools; the purpose itself differentiates it, so no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool requires specific API credentials, falls back gracefully when not configured, and provides a list of output fields only 'when configured.' It also states 'zero delay' as a performance trait. It doesn't cover edge cases like invalid symbol handling or rate limits, but the provided information is substantial and honest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, front-loaded with the core purpose in the first sentence. It is longer than minimal but every paragraph contributes essential information (credentials, setup, fallback, output specifics, examples). The pricing comparison with Zerodha is arguably extraneous, but it does help justify the tool's value. Overall, it is reasonably concise for the amount of context provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description correctly avoids duplicating return types. It covers the full lifecycle: what the tool does, prerequisites, setup steps, fallback behavior, and concrete examples. It also explains the distinction from paid alternatives and lists the exact data fields provided. This is sufficient for an agent to use the tool correctly and to guide a user through setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares 'symbol' as a string with no description. The tool description compensates fully by defining it as an 'NSE symbol' and giving examples: 'RELIANCE, TCS, NIFTY, BANKNIFTY.' It also shows concrete usage examples ('live_quote("RELIANCE")'), which adds practical meaning far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Real-time NSE quote via Angel One SmartAPI — zero delay, no yfinance lag.' It specifies the exact resource (NSE quotes) and distinguishes from alternatives by emphasizing real-time data and the specific broker API. This leaves no ambiguity about what the tool does and how it differs from sibling quote tools like 'nse_quote' or 'stock_quote'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for real-time NSE quotes without delays, needing Angel One credentials, and with a graceful fallback if not configured. It mentions the paid alternative (Zerodha Kite Connect) and implies the tool is free for account holders. However, it does not explicitly name sibling tools or state when *not* to use it (e.g., if the user lacks Angel One credentials), so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool calculates PCR data itself ('We calculate it free') and lists the specific outputs (OI-based/volume-based PCR, overall sentiment signal, bull/bear/neutral interpretation, total OI). It does not discuss data freshness, error handling, or limitations, but for a read-only data tool this is reasonable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead purpose statement, a brief value-add note about cost, a bullet list of outputs, and an Args/examples section. The Sensibull Pro pricing line is extraneous but not disruptive. The content is front-loaded and every section serves a purpose, though it could be slightly trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter and an output schema exists, the description need not detail return structures. It covers purpose, inputs, outputs, and usage examples adequately. For its complexity level, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the parameter name, type, and default with no description (schema coverage 0%). The description compensates fully with an 'Args' section stating 'num_expiries: Number of expiries to analyze (default 5)' and two usage examples that illustrate the parameter's effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Nifty PCR (Put-Call Ratio) trend across multiple expiries — market sentiment gauge.' It specifies the resource (Nifty PCR), the scope (multiple expiries), and distinguishes it from siblings like options_oi_analytics and nse_options_chain by focusing specifically on PCR and sentiment interpretation. The 'Provides:' list further clarifies the exact outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description labels the tool as a 'market sentiment gauge' and provides examples of usage (nifty_pcr_trend() and nifty_pcr_trend(3)), which clearly implies when to use it. However, it does not explicitly mention alternatives, exclusions, or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the threshold rule (0.5% of total shares) and that no arguments are needed, adding meaningful behavioral context beyond the tool name. It doesn't describe output format or data freshness, but these are not critical for a simple read-only data fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the primary action, adds a qualifier, suggests a use case, then gives an example. Every sentence contributes without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only tool with an output schema in place, the description covers the essential elements: what it does, the transaction threshold, the use case, and an example invocation. There is no missing information that would impede correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description confirms this with 'No arguments needed' and provides an example call, which is sufficient given there is nothing else to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recent bulk and block deals on NSE', using a specific verb and resource. It also explains the qualification threshold (quantity exceeding 0.5% of total shares), distinguishing it from quote or historical data tools like nse_quote or nse_historical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions usefulness for 'tracking institutional activity', which provides clear context for when to use it. However, it does not name alternatives or explicitly state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains this is a read-only look at sector indices, the list of covered sectors, and that best/worst performers are highlighted, adding meaningful context beyond the empty schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a helpful example. Every sentence adds value and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an existing output schema, the description is complete: it identifies the data source, the specific sectors, the time period, and the best/worst highlight feature. No further return-value detail is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no properties. The description explicitly states 'No arguments needed' and includes a call example, fully satisfying the parameterless baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves performance of Nifty sectoral indices, names specific sectors, and mentions highlighting best/worst performers. This distinguishes it from broader market indices and individual stock tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage is clear: call it to see today's Nifty sector performance, and the example plus 'No arguments needed' specify exactly how to invoke it. It does not explicitly list alternatives or when-not-to-use cases, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It transparently discloses the returned data (current price, % change, market cap, top 5 gainers/losers) and the argument behavior, but does not mention error handling or real-time limitations. This is adequate for a simple read-only data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-line purpose, a brief summary of returns, an args section, and useful examples. Every sentence adds value and the format is easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (one parameter), and the description explains its behavior and inputs completely. An output schema exists, so detailed return formatting is not required. The description even includes edge cases (nifty50 vs sensex) and highlights the top gainers/losers feature, making it complete for the described scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema property lacks a description (0% coverage), but the description compensates by explicitly stating the valid values ('nifty50' or 'sensex'), the default, and even provides examples. This gives meaning beyond the raw schema and helps the agent invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('list of stocks in Nifty 50 or Sensex'). It differentiates itself from sibling tools by focusing on index constituents with live prices, not individual quotes or index levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (getting all index components with prices and top movers), but it does not explicitly mention alternatives or when not to use it. The context is sufficient for basic selection among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It effectively communicates that this is a read-only screening operation, indicates the 'PRO' requirement, and explains the filtering logic including the '0 = no filter' convention. It doesn't detail rate limits or data freshness, but for a screener these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, a detailed args section, and practical examples. It is somewhat verbose due to the number of parameters, but each section earns its place and the information is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters) and the lack of both annotations and schema-level descriptions, this description is remarkably complete. It covers the stock universe, all filter criteria, the PRO requirement, and provides multiple examples that illustrate realistic usage. An output schema exists, so the absence of return-value documentation is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully documents all 9 parameters with meanings, units, examples, and default behaviors. This goes far beyond the bare schema and gives the agent everything needed to set meaningful filter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Screen stocks by multiple financial criteria,' which is a specific verb+resource statement that immediately defines the tool's purpose. It further clarifies the scope by naming Nifty 50 and S&P 500 and listing concrete filter metrics (P/E, ROE, market cap), making it clearly distinct from sibling quote/historical tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, with examples like 'Value stocks with high ROE' and 'High dividend yield stocks.' While it doesn't explicitly name alternatives or state when not to use it, the screening focus is evident and the examples serve as practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing conditional behaviors: XIRR only if buy_date provided, sector concentration flag at >40%, single stock >30% flag, and FII reducing risk. It doesn't cover error handling or data freshness, but the disclosed behaviors are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for input format, returns, and args. The example is concise and relevant. Every sentence contributes meaning, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex analytical tool, but the description covers input structure, optional fields, return metrics, and risk flag thresholds. Since an output schema exists, the return-value description is a bonus, making the tool fully self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, but the description compensates with a concrete JSON example and an Args section that defines the structure of each holding, including optional buy_date. This is a strong addition beyond the schema's bare 'additionalProperties: true' array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Portfolio X-ray: deep risk + return analysis for your holdings,' which clearly states the tool's function using a specific verb and resource. It differentiates this tool from single-stock tools like stock_quote and even the sibling portfolio_analysis by emphasizing risk flags, sector concentration, and diversification scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use it: when a user provides a list of holdings for return and risk analysis. It includes the input format and expected output. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses core behavior: tests crossover signals, compares vs buy-and-hold, and accepts custom parameters. It does not mention potential limitations (e.g., data frequency, survivorship bias), but for a computational backtest tool, the essential behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the strategy logic up front, followed by a concise parameter list and illustrative examples. Every sentence adds value, and the length is appropriate given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown), so return values need not be described. All input parameters are fully documented with examples. Strategy details and customization options are clear, making the tool easy to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully compensates by explaining every parameter with type, default, and meaning (e.g., 'short_window: Short SMA period in days (default: 20)'). It also provides three examples showing different parameter combinations, adding deeper meaning than the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Backtest a Simple Moving Average (SMA) crossover strategy,' which uses a specific verb and resource, clearly distinguishing it from sibling data-retrieval tools. It also outlines the trading logic (buy/sell on crossovers) and the comparison to buy-and-hold, making the tool's function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the strategy mechanics and backtest scope, but it does not explicitly contrast with alternative tools like technical_indicators or stock_historical. It implies usage context through the strategy description and examples, but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tax computation rules (20% STCG, 12.5% LTCG above exemption, debt fund slab rate, loss carryforward) and the return format (formatted summary). This is strong behavioral context, though it does not address edge cases or disclaimers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (rules, args, examples). It is longer than average, but that length is justified by the tax complexity and parameter count. It front-loads the purpose and uses bullets for readability, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and a complex domain, the description is remarkably complete. It covers all required params, provides a worked example, and explains return type. The output schema exists, so further return details are unnecessary. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain params. It does so thoroughly: buy_price/sell_price as INR, buy_date/sell_date with DD-MM-YYYY format, quantity integer, asset_type enum values, and symbol optional. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Calculate Indian LTCG / STCG tax liability for an equity or mutual fund trade.' It uses a specific verb ('Calculate') and resource ('tax liability') and scopes it to Indian equity/MF trades, distinguishing it from the many quote/analytics siblings. No other sibling tool appears to handle tax computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for capital gains tax on equity/MF trades and provides detailed tax rules (post July 2024 Budget). However, it does not explicitly mention when not to use it or alternatives. Given the sibling list contains no other tax tool, it is clear, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the tool accepts a comma-separated symbol string, enforces a 2-5 stock limit, and returns a comparison table with specific financial metrics. This is transparent about inputs and outputs, though it doesn't mention data sources or real-time availability, which is acceptable 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a bullet-like list of output metrics, an args section, and three relevant examples. Every part adds value; the examples are especially useful for understanding input format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (one parameter, comparison output), the description is complete: it provides the input format, valid range, examples, and output contents. The presence of an output schema further reduces the need to describe return structure, so no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'symbols' as a string with no description. The description compensates fully by specifying the exact format ('Comma-separated stock symbols (2-5 stocks)'), providing multiple examples, and clarifying the expected semantics. This is far beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Compare 2-5 stocks side by side' and lists exact metrics displayed. This clearly distinguishes it from siblings like stock_quote or technical_indicators that focus on single-stock or other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples demonstrate when to use the tool (e.g., 'Compare 3 Indian IT giants', 'Compare US tech', 'Compare banks') with concrete symbol lists. While no explicit exclusions or alternatives are stated, the context is clear that this tool is for multi-stock comparisons, which differentiates it from single-stock tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently lists the 6 input signals, the output fields, and gives an example. It does not disclose the exact weighting methodology or caveats about accuracy/uncertainty, but it does communicate that the output is a probability and provides signal labels, which is sufficient for an agent to know 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded purpose sentence, bullet-point lists for signals and output fields, and a concise example. Every sentence adds value; there is no redundant or filler content. The length is appropriate for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with an output schema, the description is exceptionally complete. It covers the purpose, the methodology (aggregating 6 signals), the output structure with example values, and provides a natural-language example. An agent can invoke this tool and interpret its results without any additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema provides no parameter information. The description compensates richly by explaining the underlying data inputs (RSI, FII flow, Put/Call ratio, India VIX, G-Sec yield, GIFT Nifty), giving the agent meaningful context about what drives the computation beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute') and clearly states the resource ('probability that Nifty 50 closes UP in the next trading session'). It distinguishes itself from sibling tools by explicitly aggregating 6 named market signals into a single percentage score, which is a unique capability among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for getting a next-session direction probability for Nifty 50. However, it does not explicitly mention when not to use it or name alternatives (e.g., technical_indicators for standalone indicators). It implicitly differentiates itself by focusing on an aggregated outlook, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining how signals are logged automatically when get_stock_brief or get_stock_debate runs, the 7-day price check, and the correct/wrong/neutral labeling. This adds meaningful context about the data pipeline and outcome determination. It could go further by disclosing data freshness or batch processing, but the provided information is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear lead sentence, a brief pipeline explanation, bullet-pointed use cases, and a compact Args/Returns section. Every sentence earns its place, and the format is easy to scan. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with a data pipeline, and the description covers all needed context: data source, outcome labeling, use cases, parameters, and return summary (accuracy %, avg 7-day return, breakdown by signal type, top symbols). Since an output schema exists, the return-value summary is sufficient. The description is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly with an Args section explaining each parameter: source (with possible values 'brief', 'debate', 'score', or '' for all), symbol (NSE symbol or all), and days (look-back window with default 30). This adds full meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Show how accurate FinStack signals have been — backed by real outcome data.' It clearly distinguishes itself from sibling tools like get_signal_history (history of signals) and check_signal_outcomes (check specific outcomes) by focusing on aggregate accuracy statistics with a 7-day outcome window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('Use this to: prove...', 'Find which signal source...', 'Find which stocks...') which give clear context for when to invoke this tool. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks explicit exclusions. The guidance is still strong enough to steer an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses scraping sources, classification, fallback to yFinance, and requires API setup for real data. It does not mention potential delays or failure modes, but is fairly transparent for an API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Setup). It is slightly long but every sentence adds value, including the optional setup instructions and fallback note. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with external APIs and a fallback, but the description covers all essential aspects: purpose, input parameters, return fields, setup, and fallback. An output schema exists, but the description still provides a convenient summary. Very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: 'symbol' with examples (RELIANCE, TCS, INFY) and 'limit' with default and max values. This exceeds what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze social media sentiment for any NSE stock using Reddit + Twitter.' It specifies the action (analyze), the resource (social media sentiment for NSE stocks), and is distinct from sibling tools which focus on quotes, financials, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool (to get social sentiment for NSE stocks) and includes a fallback behavior. However, it does not explicitly mention alternatives or when NOT to use the tool, which would have made it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It openly discloses the scope of returned data (valuation, profitability, growth, etc.) and market coverage (Indian/US). It does not mention potential errors, data freshness, or permission requirements, but for a simple data retrieval tool, the disclosure is adequate and adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, bulleted metric categories, market scope, Args, and examples. Every line serves a purpose: the categories tell the agent what to expect, the market scope prevents misapplication, and examples illustrate correct invocation. It is concise enough for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema exists, the description is complete. It specifies input format, output content categories, market applicability, and realistic examples. There are no ambiguous aspects left for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'symbol' as a string with no description. The description explains the symbol parameter in the Args section with examples (RELIANCE, TCS, AAPL, MSFT) and contextualizes it in the Examples. This fully compensates for the 0% schema coverage and gives the agent clear guidance on what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get key financial ratios and valuation metrics for a company.' It enumerates specific metric categories (valuation, profitability, growth, etc.) and provides examples for both Indian and US stocks, distinguishing it from financial statement or technical indicator tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (when ratio/valuation analysis is needed) and notes it works for Indian and US stocks. It does not explicitly compare with alternatives like income_statement or technical_indicators, but the purpose is specific enough to imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format and the optional behavior when the symbol is left empty. It doesn't mention error handling or rate limits, but as a 'Get' tool, the read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose, return format, args, and examples. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema present, the description covers purpose, parameter semantics, and examples sufficiently. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'symbol' as a string with a default, but the description explains its meaning, optionality, and behavior when empty. Concrete examples with AAPL and RELIANCE.NS further clarify usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets market news for a stock or the general market, with a specific return format (up to 10 articles with title, publisher, and link). This distinguishes it from sibling tools focused on quotes, historical data, or analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the optional symbol parameter and provides examples for both company-specific and general market news. It doesn't explicitly mention alternatives or when not to use it, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data source (AMFI database), states that no API key is required, and provides examples of return values (NAV, change, 7-day history). This goes beyond a minimal description, though it does not cover error cases or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It front-loads the primary purpose, adds a brief note on the data source and authentication, and then presents clear args and examples. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and an output schema, the description is remarkably complete. It explains the input format, provides examples, states the data source, and hints at the return content (NAV, change, history). This leaves little ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'query' parameter with zero description coverage. The description compensates fully by explaining that 'query' accepts either a fund name or a numeric scheme code, with concrete examples. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the latest NAV and details for any Indian mutual fund.' It clearly differentiates from sibling tools like stock_quote by focusing on mutual fund NAV. The examples further reinforce the purpose by showing fund names and scheme codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for any Indian mutual fund NAV lookup. It gives examples of valid queries, implying usage. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the tool is a scanner (read-only) and specifies the Nifty 500 universe, adding behavioral context. It doesn't mention rate limits or auth, but for a market data tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a summary line, a detailed explanation, and examples. Every sentence adds value; there is no fluff or redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, so return values are covered externally. The description covers what it does, the scope (Nifty 500), valid parameter values, and examples. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists a parameter with a default, but the description defines all valid values ('upper', 'lower', 'both') with explicit meanings and examples. This fully compensates for the 0% schema coverage and adds essential semantic meaning beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Scan NSE stocks currently hitting upper or lower circuit limits' with a specific verb and resource. It distinguishes from sibling market tools by focusing on circuit-locked stocks, not just any movers or quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it checks Nifty 500 stocks for stocks frozen at intraday high or low. It does not explicitly mention alternatives or exclusions, but the scope is well-defined. Examples illustrate intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the transparency burden. It discloses output content (OHLCV + summary stats) and a concrete limitation ('1m data only available for last 7 days'). It does not cover error handling or data adjustment details, but for this tool the disclosed information is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, then provides structured Args and Examples sections. Every section adds value, and the examples are especially useful for parameter combinations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to itemize the return object. It covers the required parameters, valid options, and a data-availability caveat, making it complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are entirely absent (0% coverage). The description compensates by listing each argument, providing valid value sets for period and interval, examples, and a special constraint for the 1m interval.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Get historical price data (OHLCV) for an NSE stock'), states the returned fields, and notes summary stats. This distinguishes it from sibling tools like nse_quote (current quote) and crypto_historical (non-NSE).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implicitly defines when to use it (historical NSE stock data) through the description and examples, but it does not explicitly mention alternatives or when-not-to-use cases relative to siblings like stock_historical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral traits: it is limited to Nifty 50 components, returns exactly top 10 stocks, and uses 'today's' performance (implying time-sensitivity). It doesn't cover edge cases like market holidays or after-hours behavior, but for a simple read tool it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It uses short sections (Args, Examples) and every sentence adds value. It is informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is complete. It explains the parameter options, gives examples, and clarifies the Nifty 50 scope and top-10 limit. The output schema exists, so detailed return values are not needed in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with no description (0% coverage), but the description fully compensates by explaining the three accepted values (gainers, losers, active) and what each returns. The examples also clarify the expected input format. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get today's top performing stocks on NSE' and specifies it returns the top 10 stocks from Nifty 50 components. This is a specific verb+resource+scope, and it distinguishes itself from sibling tools like nse_quote or nse_market_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage is clearly implied through examples ('nse_top_movers("gainers") → Today's top gainers') and the description of the mover_type options. However, it does not explicitly mention when to use this tool over alternatives or any exclusions, so it lacks direct sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that indicators are computed locally and incur no API cost, which is useful behavioral context. It also implies a read-only, synchronous calculation. However, it does not mention potential latency, data source dependencies, or whether the buy/sell signals are derived or user-interpreted—minor gaps given the tool's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence purpose, a list of indicators, market scope, and a formatted Args section followed by practical examples. Every sentence adds value, and the markdown formatting improves scannability without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage and an output schema exists, the description provides all necessary context for invocation: parameter meanings, default values, allowed values, and examples. It covers both basic and advanced usage scenarios, making it complete for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains every parameter with allowable values (period: 3mo, 6mo, 1y, 2y; indicators: comma-separated list with exact option names; symbol: examples like RELIANCE, AAPL) and clarifies the default behavior ('Leave empty for ALL indicators'). Examples show positional argument order, which adds significant meaning beyond the schema's bare string types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb phrase 'Compute technical indicators for a stock with buy/sell signals' and enumerates the exact indicators (RSI, MACD, SMA, EMA, Bollinger Bands, ATR, Stochastic, ADX, OBV). This clearly distinguishes the tool from siblings that focus on quotes, historical data, or fundamental analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on supported markets ('Indian (NSE/BSE) and US stocks') and gives concrete usage examples with different parameter combinations. It does not explicitly state when to prefer this over alternatives or exclude scenarios, but the examples and indicator list make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states that this is a search operation and describes the return values (company info/CIK and link). However, it does not mention edge cases like invalid symbols or network dependencies, though these are not critical for a simple 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary, return-value note, explicit alternative usage, an Args section, and examples. Every sentence adds value without unnecessary verbosity, making it easy for an agent to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter search tool, the description is complete. It explains what the tool returns, how to use it, and how it relates to the sibling sec_filing tool. The output schema exists, so detailed return-field documentation is not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the parameter name and type ('symbol': string) with no description (0% coverage). The description fully compensates by defining the parameter as 'US stock ticker' and providing concrete examples (AAPL, MSFT, GOOGL), which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search SEC EDGAR for a company and get their filing page.' It specifies the action (search), the resource (SEC EDGAR), and the return value (CIK and filing page link). It also distinguishes itself from the sibling tool sec_filing by explicitly noting that sec_filing retrieves specific filing documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'Use sec_filing() to get specific filing documents' instruction, which tells the agent when to use this tool versus the alternative. It also provides clear usage context: this tool is for finding a company and getting the CIK/filing page link. Examples further clarify intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the sequential 3-round process, including each round's purpose, that agents can change their minds, and the returned fields (rounds, debate_edges, minds_changed, final_consensus). This gives a clear picture of 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence, round breakdown, an interpretive tip, and clear Args/Returns sections. Every sentence adds value; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex tool with multiple rounds and rich output (including nested fields), the description thoroughly covers the process, return structure, and interpretation cues. An output schema exists, but the description still provides needed context beyond it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'symbol' is fully explained in the description as 'NSE stock symbol (e.g. RELIANCE, TCS, HDFCBANK)', adding examples and exchange context not present in the minimal schema (which just says 'string'). This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '3-round sequential debate: AI agents read each other's arguments and rebut.' It clearly states the tool's function and explicitly contrasts it with get_stock_brief (parallel analysis), distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names an alternative ('Unlike get_stock_brief (parallel analysis)') and provides usage context by explaining the debate format. The 'Watch for minds_changed... signals a complex setup worth closer attention' gives practical guidance on when to use the tool or how to interpret results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tanmaymish/MarketPulse-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server