finstack-mcp

Server Quality Checklist

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

Latest release: v0.3.2
Disambiguation4/5
Most tools have distinct purposes clearly separated by asset class (crypto_, nse_, stock_) or function (financial statements vs. technical analysis). Minor ambiguity exists between the three quote tools (nse_quote, bse_quote, stock_quote) and historical data tools which could be confused if an agent doesn't know which market a symbol belongs to, but descriptions clarify the scope.
Naming Consistency3/5
Tools follow logical grouping patterns (nse_ prefix for Indian market tools, crypto_ for crypto, sec_ for SEC filings) but mix conventions. Some use snake_case descriptors (income_statement), others use _tool suffix (compare_stocks_tool), and financial statements use accounting terminology without prefixes while technical tools use descriptive verbs (backtest_strategy, support_resistance).
Tool Count2/5
With 39 tools, this significantly exceeds the threshold where count becomes unwieldy (25+). The breadth covers multiple exchanges and asset classes, but significant consolidation is possible—quote and historical data tools could be unified with exchange/asset parameters rather than having separate nse_quote, bse_quote, stock_quote, and crypto_price tools.
Completeness4/5
Excellent coverage for equity analysis across Indian and US markets including fundamental data (financial statements, ratios), technical analysis (indicators, backtesting), derivatives (options chain), and portfolio management. Minor gaps in fixed income/bonds and futures markets prevent a perfect score, but core equity workflows are fully supported.
Average 4.1/5 across 39 of 39 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 25, 2026
- 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.
Tools from this server were used 2 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is not a claim of the full live system's accuracy and is meant as a defensible evaluation layer. However, with no annotations, it lacks details on safety (e.g., read-only nature), auth needs, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose, followed by important caveats and parameter list. No fluff, but the structure could be tighter with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, one required) and existence of an output schema, the description provides moderate completeness. It covers limitations but omits behavior like whether the tool modifies state or requires specific permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It briefly explains lookback_months as 'historical window for checkpoints' and holding_days as 'forward return horizon for hit evaluation', but symbol is merely 'NSE symbol'. The semantics are minimal and could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates signal quality, serving as a lightweight evaluation/proof layer for the signal engine's price-action core. It distinguishes itself by emphasizing honesty and defensibility, but could better differentiate from siblings like get_signal_accuracy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description merely mentions it is an honesty tool and a proof layer, leaving usage context to inference. Given the many sibling tools, this is a significant gap.
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 provided, so description must convey behavior. It adds context about severity classification and historical significance, but lacks details on read-only nature, error handling, or rate limits. The description adds some value beyond structural elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes a promotional quote and example that add length without critical information. It could be more streamlined while retaining essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers purpose and parameter usage. However, it does not describe output format or specify behavior for invalid inputs, leaving some gaps. Generally adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines the 'sector' parameter with a default. The description expands with examples ('Banking', 'SME/Micro', 'Broking') and clarifies that 'all' provides full report. Since schema coverage is 0%, the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches SEBI orders and classifies them by severity and sector, with a purpose of early warning. However, it does not explicitly distinguish from sibling tools, though no sibling seems directly analogous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies use for monitoring regulatory actions but does not mention when not to use or suggest other tools, leaving the agent without clear decision context.
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 lists the types of data provided but lacks details on limitations (e.g., only top 1000 companies, data freshness), error handling, or authentication. It implicitly mentions the scope via SEBI mandate but does not disclose behavioral traits like rate limits or response format beyond what is listed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose but includes several paragraphs of background (e.g., comparison to paid sources) that are informative but not essential for tool invocation. The list of disclosures adds redundancy. It could be trimmed to improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of output schema, the description sufficiently covers what output to expect, including specific data types like filing links and disclosure categories. It is complete enough for a data retrieval tool, though it does not mention potential errors or empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'symbol' is described as NSE stock symbol with concrete examples (RELIANCE, TCS), adding meaning beyond the schema which only defines type string. This compensates well for the 0% schema description coverage, though it does not include constraints like uppercase or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides BRSR ESG data for listed companies, including filing links and disclosures. While it does not explicitly start with a verb, the purpose is unambiguous and specific. It does not explicitly differentiate from siblings but is sufficiently 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides background on BRSR mandate and free availability but does not explicitly guide when to use this tool versus alternatives. No exclusions, prerequisites, or contextual usage tips are given, leaving the agent without clear 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 provided, the description carries full responsibility for behavioral disclosure. It only states the tool returns historical OHLCV candles, but omits critical details like rate limits, authentication requirements, data freshness, error handling, or the return format. This is insufficient for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, using a docstring format with a clear block for arguments. The list of interval options is necessary but slightly lengthy. Overall, every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (context signal), the description does not explain the return format or any data structure. It lacks details on date ranges, pagination, or potential limits. For a financial data tool with no annotations, the description is too sparse to be fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so by specifying that 'symbol' is an NSE symbol with an example (RELIANCE), listing all interval options, and clarifying 'days' as 'Number of days of history'. This adds meaningful semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches historical OHLCV candles from the Fyers API v3, and lists the interval options and parameters. The name 'fyers_candles' distinguishes it from other candle tools like icici_candles or nse_historical, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as icici_candles or stock_historical. It does not mention prerequisites, limitations, or exclusions. The user is left to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits such as read-only nature, permissions, or side effects beyond stating what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is efficient and front-loaded, containing no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description is complete enough to understand the tool's purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline 4 applies. The description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns basic server metadata and useful links, specifying both verb and resource. However, 'basic server metadata' is somewhat vague and could benefit from more specificity, and it does not differentiate 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context, exclusions, or alternatives are mentioned. With many sibling tools, this lack of guidance increases risk of incorrect 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?
No annotations provided. The description only lists components and outputs, lacking disclosure of behavioral traits like read-only nature, permissions, rate limits, or any side effects. As a data retrieval tool, it is likely read-only, but this is not 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a bullet list, front-loaded with the main result. It includes detailed component names, which could be seen as slightly verbose but still reasonably concise. Every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (not shown) so return values are covered. Description lists return fields adequately for a scoring tool. However, it lacks usage context and does not guide the agent on when this composite score is appropriate compared to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'symbol' with no schema description (0% coverage). However, the meaning is obvious (stock ticker). The description does not add further meaning, but for a single, clear parameter, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a stock ranking score (0-100) with signal, automation_rank, top supports/risks, and full component breakdown. It differentiates from sibling tools like get_stock_brief or technical_indicators by being a composite score from multiple signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among siblings, there are many analysis tools (check_signal_outcomes, evaluate_signal_quality, get_signal_accuracy) but the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes the analysis and return values but does not explicitly state that the tool is read-only or non-destructive. It also omits details on rate limits, data freshness, or error handling. For an analysis tool, the disclosure 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, input format, and output list. It is reasonably concise but could be trimmed slightly (e.g., the output list could be more compact). Overall, it balances detail and readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and that an output schema exists (though not shown), the description covers key return values. However, it lacks details on error cases, data sources, or time periods for analysis. The presence of sibling tools like 'portfolio_analysis' suggests potential gaps in scope differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving parameters undefined. The description compensates fully by specifying the required fields (symbol, qty, avg_price) and the optional buy_date, along with a concrete example and array format. This adds essential meaning beyond the generic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'deep risk + return analysis for your holdings' and lists specific outputs like P&L, XIRR, sector concentration, and risk flags. This makes the tool's purpose specific and actionable. However, it does not explicitly differentiate from the sibling tool 'portfolio_analysis', which may cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. With many sibling tools, especially 'portfolio_analysis', it does not explain scenarios where one is preferred over the other. No 'use this when' or 'instead of' hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It omits any mention of data freshness, pagination, rate limits, or error handling. The tool is clearly read-only, but this is not stated explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using bullet points for key return fields and a clear args/examples section. Every sentence adds value, and the structure is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated), the description adequately explains return values. It covers main use cases but lacks details on error scenarios or edge cases like invalid symbols.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains both parameters thoroughly: symbol with examples of valid tickers, quarterly with explanation of default behavior. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves cash flow statements and lists specific components. Examples with different stocks and quarterly toggle clarify usage. It distinguishes itself from siblings like balance_sheet and income_statement implicitly, but does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cash flow analysis through examples and listed metrics. However, it does not explicitly state when to use or avoid this tool compared to siblings, nor does it mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention any traits like rate limits, data source, error handling, or read-only nature. The agent gains no insight beyond the basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line plus a bulleted list of args and two examples. Every sentence serves a purpose, and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values need not be explained. However, the description omits context like timezone, data source, or whether data is adjusted for splits/dividends. It is minimally complete for a simple historical data tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explicitly lists the three parameters (symbol, period, interval) and provides acceptable values and examples, which adds meaning beyond the schema's empty fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get historical cryptocurrency price data' with a specific verb and resource, and the examples further clarify the tool's purpose. It effectively distinguishes from siblings like crypto_price (current price) and stock_historical (stock data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as crypto_price for live prices or stock_historical for stocks. The description does not mention scenarios or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, requires authentication, or has any side effects. 'Check' suggests a read operation, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded with the key action and resource. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate given zero parameters and the presence of an output schema. However, it lacks detail on what the status includes (e.g., connection status, API enabled) and no annotations are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description adds meaning by explaining the tool's purpose, meeting the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks Fyers API v3 configuration status and setup instructions. It uses a specific verb ('check') and resource ('Fyers API v3 configuration status and setup instructions'), distinguishing it from sibling tools like fyers_candles, fyers_live_quote, and broker_setup_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as broker_setup_status or icici_status. The description implies usage for Fyers status but does not state when not to use it or provide context for 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?
No annotations provided, so description carries full burden. It states it returns OHLCV data but lacks details on rate limits, authentication, error handling, or behavior with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two short paragraphs; first states purpose and interval options, second lists parameters. Every sentence contributes necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be described. However, tool lacks behavioral context and usage comparison with siblings. Adequate for basic use but missing guidance for choosing among similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (0% coverage). Description compensates by explaining symbol format, interval options (1m,5m,30m,1h,1d), and days default, adding clear context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides historical OHLCV candles from ICICI Breeze API, specifying interval options and parameter details. It differentiates from sibling tools like fyers_candles and nse_historical by naming the data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It lists interval options and defaults but does not mention when-not to use or compare with other historical data tools.
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 full burden. It mentions the data source (World Bank) and that it is free, but does not disclose data freshness, update frequency, rate limits, or what happens if data is unavailable. The list of provided metrics is useful but behavioral traits are largely missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with a clear first line and bullet list, but the pricing paragraph ('Bloomberg and Refinitiv charge...') is extraneous for tool selection and adds length. The example is helpful. It could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description adequately explains what the tool returns and its source. It lists all indicators and includes a usage example. Minor gaps: units of measurement are not mentioned, but overall the description is sufficient for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema coverage is 100%. The description adds value by enumerating the specific indicators returned, which is beyond what the schema provides. With no parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides India macroeconomic indicators from the World Bank, listing specific indicators like CPI inflation, GDP growth, current account, etc. It distinguishes itself from siblings (e.g., rbi_policy_rates, india_gsec_yields) by covering a broad set of macro 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for general macro data retrieval, exemplified by 'india_macro_indicators() → Latest India macro data'. However, it does not explicitly state when to use this vs. other macro tools like rbi_policy_rates or india_gsec_yields, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions free access and lookback max ~365 days, but does not cover rate limits, auth requirements, symbol case-sensitivity, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with bullet points and examples, making it scannable. A few sentences could be tightened, but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values are covered. Description explains data fields, parameters, and unique value. No major gaps for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant value: explains symbol as NSE stock symbol with examples, days as lookback period with default and max. Examples illustrate usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows NSE insider trading and SAST disclosures for a stock, listing specific data points. It implies a unique value proposition (free vs paid tools) but does not explicitly contrast with sibling tools like 'get_insider_signal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for accessing insider trading data for NSE stocks, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_insider_signal). No when-not or exclusions 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 provided, the description carries full burden. It mentions data sources (NSE free vs Screener.in Pro paid) but does not disclose whether the tool requires authentication, pricing, rate limits, or other behavioral traits. The risk explanation is useful but does not cover tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically structured: purpose, data source, risk implication, output fields, parameter, examples. It is front-loaded with the core purpose, though the risk explanation adds some verbosity. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description need not detail return values—but it still lists output fields, which is helpful. Missing edge cases or error handling for invalid symbols, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'symbol'. The description compensates by clearly stating it is an NSE stock symbol and providing examples (RELIANCE, TCS, ADANIENT), which adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns promoter pledge percentage and risk signals for a stock symbol, with a list of output fields. However, it does not explicitly differentiate from sibling tools like 'get_pledge_alert' or 'scan_pledge_risks', which may have overlapping 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking promoter pledge risk but does not specify when to use it over alternatives. No exclusions or alternative tool names are mentioned, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions 'computed locally, no API cost' but lacks explicit read-only declaration, side effects, or other behavioral traits. Does not state that it is safe and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with an Args section and examples, making it easy to parse. Though slightly verbose with examples, each part adds value. Could be more concise, but structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers tool purpose, parameters, and markets. With an output schema present, lack of output description is acceptable. However, for a complex tool with many indicators, it could mention performance or data source details. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains each parameter clearly with defaults, options, and examples. Period values listed, indicators options enumerated, and examples illustrate usage, compensating well for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes technical indicators for stocks with buy/sell signals, listing specific indicators and markets. The verb 'Compute' and resource 'technical indicators' are specific, distinguishing it from sibling tools like 'nse_historical' or 'options_greeks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and parameter details but does not explicitly state when to use this tool over alternatives (e.g., 'stock_quote' or 'nse_historical'). No when-not-to-use or competing tool mentions.
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 provided. Description states it returns real-time data with price, change, volume, etc., but does not disclose side effects, auth needs, or data freshness. Adequate for a read 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs with clearly separated args and examples. No fluff. Could be slightly more structured but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (1 param) and presence of output schema (context signal), description covers return fields and parameter. Adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% but description adds examples (e.g., RELIANCE, TCS) and explains symbol field meaning, compensating effectively. Parameter is well-illustrated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get real-time BSE quote for an Indian stock' with specific verb and resource. It lists return fields and distinguishes from siblings like nse_quote by explicitly naming the exchange.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives. Does not mention prerequisites, exclusions, or context where it should not be used.
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 exist, and the description does not disclose behavioral traits such as data freshness, pagination, rate limits, or error handling. While it is a read operation, the description fails to add context beyond listing event categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose statement, a one-line usage hint, and a two-line Args section. No redundant or extraneous words, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so missing return value details are excusable. However, the description lacks specifics on event ordering, date range scope, or the precise type of events included beyond the listed categories. It is adequate but incomplete for a timeline tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an explicit Args block explaining 'symbol: NSE symbol (e.g. RELIANCE, HDFCBANK, TCS)' and 'max_events: max timeline events to return', adding meaning beyond the schema's raw property names and types. The default for max_events is noted in the schema but clarified in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Unified stock timeline: news, results, insider, bulk deals, sentiment, pledge, smart money' and identifies it as the 'what changed recently?' tool for a stock. This verb+resource combination distinguishes it from 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recent changes but offers no explicit guidance on when to use this tool versus alternatives like nse_quarterly_results or nse_insider_trading. No direct exclusion criteria or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists returned data but does not disclose update frequency, freshness, rate limits, or authentication needs. More behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat lengthy with bullet points and a Bloomberg comparison. It starts with purpose but includes extra information that could be trimmed. Structure is adequate but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description covers purpose and data returned. However, it lacks behavioral transparency (e.g., data freshness), leaving some gaps. Basic completeness but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is trivial. Baseline for 0 params is 4. The description adds value by specifying what the tool returns, but no parametric explanation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching India G-Sec yields, listing specific maturities and additional data. It distinguishes from siblings as no other tool in the list appears to provide G-Sec yields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for G-Sec yields by comparing with Bloomberg cost and mentioning free sources. However, it does not explicitly state when not to use or name sibling alternatives, though none exist.
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 transparency. It mentions it provides analysis for the 3 nearest expiries and claims it covers paid features for free, but does not disclose data freshness, source, or any limitations. No destructive behavior is implied, but a moderate score reflects missing details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, bullet list of outputs, Args, and Examples. The marketing sentence about Sensibull adds slight verbosity but is not excessive. Every section has a purpose, and the content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (context signal), the description need not explain return values. It adequately covers inputs, outputs, and usage examples. With no annotations, it could be more complete about usage context, but overall it provides sufficient information for an AI 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It describes the 'symbol' parameter with examples (NIFTY, BANKNIFTY, RELIANCE, TCS) but does not specify case sensitivity, format constraints, or validation rules. The examples provide some meaning but lack thorough semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Advanced options OI analytics' and lists specific outputs (Max Pain, PCR trend, IV summary, top OI strikes), distinguishing it from sibling tools like nifty_pcr_trend and options_greeks by covering a broader set of analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing features and examples, but does not explicitly state when to use this tool versus alternatives or provide exclusionary criteria. For instance, it does not mention that nifty_pcr_trend might be sufficient for PCR-only needs.
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 provided, so the description carries the full burden. It states return fields but doesn't disclose potential limitations, authentication needs, or whether the data is real-time or delayed. The description is minimal on behavioral aspects beyond the return list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two sentences for purpose, a clean list of return fields, clear argument section, and relevant examples. No fluff or redundancy; every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the essentials. It lists return fields and gives usage examples. Could mention if the profile is for the latest available data, but not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'symbol' with no description. The description adds semantic meaning by specifying 'Stock ticker (e.g., RELIANCE, TCS, AAPL, MSFT)', including examples of both Indian and US tickers. 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/5
Does 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 lists specific return fields (name, sector, industry, etc.). Examples like company_profile('RELIANCE') show typical usage. Distinguishes from siblings by focusing on profile data rather than financial statements or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples but no explicit guidance on when to use versus alternatives like stock_quote, key_ratios, or other sibling tools. No 'when not to use' or alternative suggestions are given.
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 disclose behavioral traits. It lists return values but lacks information on error handling, data coverage (e.g., all historical periods), or any prerequisites. Minimal extra context beyond the output 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a summary sentence, bullet-style return info, 'Args' section, and examples. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one required parameter and an output schema, the description covers the tool's function adequately. It explains what is returned and provides examples. However, missing details like error responses or historical depth slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'symbol' is described as a stock ticker with examples (ITC, COALINDIA, AAPL, MSFT), adding significant meaning beyond the bare schema which has no property description. Schema coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get historical dividend payments for a stock.' It specifies the returned data (dates, amounts, totals, averages, latest) and differentiates from sibling 'dividend_history_deep' by implying this is the basic version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like 'dividend_history_deep' or other stock data tools. Examples are given but no explicit when-to-use or when-not-to-use 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?
The description discloses the output format (structured JSON + morning_text) and lists the data components, but does not explicitly state read-only behavior, authentication needs, or data freshness. Without annotations, these gaps reduce transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a clear bullet list to enumerate components, and front-loads the key purpose. No wasted words, and the output format is described efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, the data components it includes, and the output format. Given the output schema exists, it need not detail return types. Minor gaps: no mention of data freshness or prerequisites, but largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The description appropriately omits parameter details, and no additional meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool compiles a comprehensive pre-market brief for Indian traders, listing specific components. It is clearly differentiated from sibling tools like get_morning_fno_brief and get_stock_brief by its scope and timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for pre-market briefing at 8:15 AM but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusion criteria or comparisons to other briefs are provided, leaving the agent to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions checking status and token instructions but does not clarify side effects, authentication requirements, or whether the operation is read-only. This is insufficient for a setup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential purpose without extraneous words. It is well front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description covers the core purpose. It could benefit from mentioning that the output includes configuration status and token details, but the output schema likely fills this gap. Slightly incomplete but still effective.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description logically adds no parameter info, but nothing is missing. Baseline score of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks ICICI Breeze API configuration status and provides daily session token instructions. This specific verb-resource pairing distinguishes it from sibling tools like icici_candles (price data) and icici_live_quote (real-time quotes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., broker_setup_status, fyers_status). The description implies it is a prerequisite for other ICICI tools but does not state this. Score is adequate but lacks clarity.
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 provided. The description does not disclose any behavioral traits such as rate limits, authentication needs, or side effects. For a read-only tool, the lack of such details is a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear summary, bullet points for arguments, and examples. No redundant text; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema (not shown), the description covers the key fields returned. It is largely complete, though it could mention output schema existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has minimal info (type, default), but the description adds a detailed list of valid index options and examples. Given 0% schema description coverage, this fully compensates and adds meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current value of Indian market indices, listing specific returned fields (value, change, high/low, 52-week range). It distinguishes from siblings by focusing on indices rather than stocks or other financial 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like nse_quote or bse_quote. The context that it is for indices is implied, but no when-not-to or direct sibling comparisons.
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 provided; description lacks disclosure of data freshness, API limits, or source. Only states output fields, not behavioral traits. Relies on minimal description for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: short summary, bullet list of metrics, args, examples. No waste, front-loaded with key info. Earns every sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, param, and output fields. Output schema exists but description doesn't detail structure; however, tool is simple and listed fields are sufficient for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'symbol' well-explained with examples (RELIANCE, TCS) in description, compensating for 0% schema description coverage. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets latest quarterly results for NSE stocks, lists specific financial metrics (revenue, profit, EPS, EBITDA) with growth rates. Distinguishes from siblings like nse_quote or stock_historical by specifying financial results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies it's for quarterly results but does not explicitly contrast with alternatives like nse_historical or income_statement. No when-not or alternative tool mentions, leaving room for ambiguity.
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?
Discloses that it returns earnings dates and analyst estimates (EPS and revenue). However, with no annotations, it does not mention any behavioral traits such as data source, rate limits, or scope (e.g., which exchanges). Adequate but could add 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concisely structured with two paragraphs plus Args and Examples sections. The examples are helpful but slightly verbose; otherwise no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not detail return values. It adequately explains the purpose and primary output (earnings dates and estimates) for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage for the 'symbol' parameter. The description compensates by stating it is a stock ticker with examples (RELIANCE, AAPL) and noting it is required, adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('upcoming earnings dates') and clearly distinguishes from sibling tools like predict_earnings and nse_quarterly_results by focusing on expected upcoming reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of usage but no explicit when-to-use or when-not-to-use guidance relative to sibling tools. Implies usage from examples but does not exclude alternatives like predict_earnings for forward-looking estimates.
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 provided; description discloses data source (public SEBI SAST) and output fields but lacks details on read-only nature, error handling, rate limits, or data freshness. The performance claim adds context but is not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise and front-loaded with the purpose. However, the marketing-like sentence about conviction signal adds some verbosity. Overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no annotations, the description adequately explains the output and usage. Missing details like return type or error handling but still sufficient for simple use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'symbol' is explained with a clear description ('NSE symbol (e.g. RELIANCE, INFY, ZEEL)') and examples in the Args section, compensating 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'Insider trading pattern analysis from SEBI SAST disclosures' and enumerates specific outputs (signal, net_signal, transactions). This distinguishes it from sibling tools like nse_insider_trading and get_signal_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for assessing insider conviction but does not explicitly state when to use this tool versus alternatives. No mention of prerequisites or conditions.
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 indicates the tool is a comparison (read-only) operation and mentions live tracking as an enhancement, but does not disclose potential side effects, authentication requirements for the base database, or data freshness. The behavioral traits are adequate 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a front-loaded purpose and inline argument documentation, but contains a verbose tweet-like quote ('I tracked 50 Indian stock tip channels for 30 days...') that adds little value and increases length. While efficient in parts, the fluff reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no required params, output schema provided), the description covers the key usage scenarios, parameter behavior, and optional live tracking setup. It lacks error handling details or data freshness notes, but is largely complete 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining the only parameter 'channel': it specifies the format (handle with @, e.g., '@NSEBSEtips') and the behavior when left empty (full comparison database). This adds complete meaning beyond the schema's default and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Telegram signal tracker that compares 50 Indian stock tip channels by accuracy, average return, and pump-and-dump probability. This verb+resource definition is specific and distinguishes it from sibling tools like 'get_signal_accuracy' or 'detect_pump', which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing Telegram stock tips and provides optional live tracking setup, but lacks explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or scenarios where another tool would be better, such as for individual signal analysis.
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 provided, so description carries full burden. It explains the meaning of each Greek but lacks details on assumptions (e.g., Black-Scholes model), data sources, rate limits, or limitations. Provides some transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: summary, benefit statement, bullet list of Greeks, Args, Examples. Every sentence adds value; could be slightly more concise but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description adequately explains input and what the tool provides. Examples clarify usage. No need to detail return structure since output schema covers it. Complete enough for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond the input schema: explains symbol as NSE stock/index symbol, expiry as optional YYYY-MM-DD with nearest default, and provides examples. Schema coverage is 0%, so description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calculates Black-Scholes Greeks for option strikes, lists and explains each Greek (Delta, Gamma, Theta, Vega, Rho), and distinguishes from sibling tools like nse_options_chain and options_oi_analytics by focusing on Greeks calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for NSE options Greeks but does not explicitly state when to use this tool vs alternatives like nse_options_chain or options_oi_analytics, nor does it provide exclusions or prerequisites. Examples are helpful but guidance is 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, the description carries full burden. It explains outputs (percentages, top holders) but omits behavioral details like data freshness, rate limits, or scope (e.g., works for all NSE stocks?). It adds value by noting free access, but lacks complete 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with bullet points and examples. It front-loads the main purpose and uses concise language, though could be slightly shorter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (ownership breakdown) and presence of output schema, the description sufficiently explains what is returned (percentages, top holders). It is complete 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must define the parameter. It clearly defines 'symbol' as NSE stock symbol with examples (e.g., RELIANCE, TCS). This adds meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides shareholding pattern breakdown (promoter, FII, DII, public) for NSE stocks. It uses specific verbs and resource, and distinguishes from siblings like 'promoter_pledge' and 'nse_quote' by focusing on ownership composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions what data is covered and that it's free, but does not explicitly state when to use this tool vs alternatives (e.g., when to use 'promoter_shareholding' vs 'company_profile' or 'nse_quote'). No guidance on when not to use or prerequisites.
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 provides good transparency by listing return data (current price, % change, market cap, top gainers/losers) and stating it returns live prices. It does not mention potential limitations like rate limits or data freshness, but for a data retrieval 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, return details, Args, and Examples. Every sentence is purposeful and information-dense, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers purpose, parameters, return data, and examples adequately. It could include additional usage notes on data accuracy or refresh frequency, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter index_name has 0% schema coverage, but the description clearly explains its values (nifty50 or sensex) with default and examples, adding meaningful context beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the list of stocks in Nifty 50 or Sensex with live prices, including specific return fields. While it distinguishes from many sibling tools through its name and function, it does not explicitly differentiate from similar tools like 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through Args and Examples, specifying valid index names and default. However, there is no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use conditions.
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?
Without annotations, the description discloses basic behavior: computing pivot points and key price levels from historical data. It does not reveal data source, accuracy, or edge cases, but the core action 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief purpose, Args, and Examples sections. It is concise but the '[PRO]' tag is unexplained. Every sentence adds value, though the examples could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description covers inputs adequately with examples. However, it lacks details on the output format or how results are structured, making it somewhat incomplete for a complex analytical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining both parameters: symbol with ticker examples and period with explicit options (3mo,6mo,1y,2y) and default. This adds substantial meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes support and resistance levels, specifically naming pivot points R1-R3 and S1-S3. This verb+resource pair is distinct and well-defined, differentiating it from sibling tools like technical_indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of usage (stock tickers and periods), implying when to use it. However, it does not explicitly state when not to use it or contrast with alternatives like technical_indicators or stock_historical, leaving room for ambiguity.
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 mentions the tool returns 'instant sector + stock impact mapping' and lists sectors detected, but does not disclose any behavioral traits like rate limits, authentication needs, or what happens if used outside the designated date.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively detailed with an example and a list of detected sectors. It is front-loaded with purpose but could be more concise; some sentences like the example could be shortened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and presence of an output schema (as per context), the description covers the use case well, including input format, output concept, and sectors detected. It is sufficient for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'text' has 0% schema description coverage. The description adds a clear semantic explanation: 'Budget speech transcript text (paste directly from live broadcast)', which is more informative than the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a 'Real-time budget speech analyzer' and specifies the use case: on Feb 1st as the FM speaks. It differentiates from siblings like 'get_budget_impact' by emphasizing real-time usage and providing an example of input-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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('on Feb 1st as FM speaks') and what input to provide ('Paste the Finance Minister's speech text'). It does not explicitly state when not to use or list alternatives, but the context 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?
No annotations provided. The description implies a read-only data retrieval but does not disclose any behavioral traits such as data latency, required permissions, or limits. It is minimally 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary, return items listed, an Args section, and examples. Every part serves a purpose with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It provides all necessary information for an agent to invoke the tool correctly, including parameter usage and example calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are explained with examples and default values. The description adds significant meaning beyond the schema, clarifying that symbol is a stock ticker and quarterly controls annual vs quarterly data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get balance sheet for a company' with a specific verb and resource. It lists the items returned and provides examples, distinguishing it from sibling tools like cash_flow and income_statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description is self-contained but fails to mention that this is for balance sheet data only, not for other financial statements or ratios.
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 discloses that it manually triggers checks, runs automatically normally, and returns the count of updated signals. It does not mention idempotency, side effects, or limitations, but covers the core 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, context, and output. No fluff, every sentence adds value. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no annotations, the description covers the essential aspects: what it does, when to use it, and what it returns. The output schema is mentioned as present, but the description already states the return value. Slightly lacking in edge cases or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to add parameter information. The baseline is 3 due to 100% schema coverage, and the description provides sufficient context about the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('trigger outcome checking') and the resource ('pending signals'). It distinguishes itself from sibling tools by focusing on outcome checking, unlike signal creation or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (force-check when windows have elapsed) and that it is normally automatic, providing context. It does not explicitly mention alternatives, but the use case 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?
The description lists return fields (current rate, change, high/low, 52-week range) but does not disclose that it is a read-only operation, nor mention rate limits, error conditions, or data frequency. Since no annotations exist, the description carries the full burden but falls short of comprehensive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, a list of return fields, an Args section, and five examples. Every sentence adds value, and the front-loading makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the presence of an output schema, the description covers essential aspects. It lists return fields and provides usage examples. However, it lacks error handling details (e.g., invalid currency codes) and data source information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear parameter semantics in the Args section (e.g., source and target currency codes with examples) and lists a default for to_currency. This compensates for the schema's lack of descriptions (0% coverage). Additional validation hints (like valid codes) could improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get live forex exchange rate between two currencies.' It uses a specific verb and resource, and differentiates from sibling tools like stock_quote or crypto_price by focusing on forex.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need forex rates), but does not explicitly state when not to use it or suggest alternative tools. No guidance on prerequisites or context.
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 disclose behavioral traits. It describes the output (flags unusual resolutions) but does not mention side effects, data sources, or limitations. The tool appears read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a summary, bullet points of flags, a contextual quote, and an Args section. While informative, it is somewhat lengthy; the bullet points and quote could be condensed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown but presence noted), so return values are covered. The description explains purpose and flags but lacks usage guidelines and behavioral transparency. For a tool with one parameter, it is fairly complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'symbol' with no description. The description adds examples (e.g., RELIANCE, ZEEL, ADANIENT) and context (NSE symbol), providing meaning beyond the schema. Schema coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides an 'AI briefing for upcoming AGM/EGM resolutions from NSE filings' and lists specific flags (e.g., large debt issuance, management salary hikes). This distinguishes it from sibling tools like get_stock_brief or get_morning_brief, which cover different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for pre-AGM/EGM analysis by listing scenarios like 'This company is passing a resolution to raise ₹500Cr debt next week.' However, it does not explicitly state when not to use or mention alternatives, though the 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?
No annotations are provided, so the description bears the full burden. It describes the output content but does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or error handling. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose and then detailing outputs and arguments. Each sentence adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple single-parameter tool with an output schema, the description adequately covers what the tool does and its parameter. It does not mention pagination or error handling, but for this use case, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'year' has a default and is described with examples ('2025', '2024', '2023'), clarifying the expected format. With 0% schema description coverage, this adds necessary context, though it could explicitly state it refers to the fiscal year.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'Historical Union Budget impact by year' and lists specific outputs (key announcements, sector winners/losers, market reaction). It distinguishes itself from the sibling 'analyze_budget_live' by focusing on historical 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical budget data but does not provide explicit guidance on when to use this tool versus alternatives like 'analyze_budget_live' or any exclusions. It lacks when-not-to-use instructions.
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 fully discloses the tool's behavior: it aggregates six specified signals, returns a probability and supporting factors, and provides raw inputs. It does not mention latency or failure conditions, but for a read-only, parameterless tool, the transparency is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence, bullet points for signals, and an example. It is slightly verbose in signal explanations but remains focused and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description fully accounts for no parameters, provides complete output schema details (fields and example), and explains all six signals. The tool's behavior is fully specified given its simplicity and available structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline score is 4. The description does not need to add parameter semantics, and it correctly omits any parameter discussion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool computes the probability of Nifty 50 closing up in the next session by aggregating six market signals. This specific verb-resource combination ('get nifty outlook') differentiates it from sibling tools like gift_nifty, nifty_index, or individual signal 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus its many siblings (e.g., gift_nifty, nifty_pcr_trend, get_signal_accuracy). The description does not indicate scenarios where this aggregated outlook is preferred over individual signal analysis.
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 provided. The description uses 'Get' implying a read operation, but does not explicitly state that it is safe or has no side effects. With no annotations, the description should more clearly indicate behavioral traits like read-only or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences plus an example. Front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's output fields and scope. Output schema exists to document return values. Could add clarity on the time range for 'upcoming and recent', but overall sufficient for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline score of 4 applies. Description adds no parameter info because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets upcoming and recent IPOs on NSE, listing the specific data fields (company name, price band, etc.). Distinguishes from many sibling tools focused on stocks, funds, or other financial instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates no arguments needed and provides an example call. While it doesn't explicitly state when to use versus alternatives, the self-contained nature and example imply its use for IPO queries. Could improve by noting that for individual stock data other tools should be used.
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 transparently lists categories of metrics returned and the geographic scope (Indian and US stocks). However, it omits potential limitations such as data lag, error handling for invalid symbols, or any destructive effects. The tool is clearly a read operation, but no explicit statement on that is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet categories and concrete examples. It is moderately concise but could be slightly tightened without losing clarity. The front-loading of the purpose is good, and each section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown here but context indicates it exists), the description need not detail return values. It covers the single parameter adequately with examples and specifies geographic coverage. It does not address potential edge cases or data freshness, but overall it is sufficiently complete for a ratio retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'symbol' has zero schema description coverage (only a title in schema). The description compensates fully by providing examples (e.g., RELIANCE, AAPL, HDFCBANK) and explaining it is a stock ticker. This adds crucial meaning beyond the schema stub.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb+resource statement: 'Get key financial ratios and valuation metrics for a company.' It further details categories like Valuation, Profitability, Growth, etc., making it distinct from sibling tools such as balance_sheet or income_statement which focus on specific statements rather than derived ratios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of usage (e.g., for RELIANCE, AAPL) and mentions it works for Indian and US stocks, implying broad applicability. However, it does not explicitly state when to prefer this tool over siblings like balance_sheet or income_statement, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists output fields but does not disclose behavioral traits like rate limits, authentication needs, or error handling for invalid symbols.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, lists key return items, then includes Args and Examples efficiently with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter and presence of output schema, the description is mostly complete. It lists return fields and examples, though it could add notes on error cases or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description adds examples and specifies the format ('NSE stock symbol, e.g., RELIANCE'), providing clarity beyond the schema's vague 'string' type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get real-time NSE quote for an Indian stock' and lists specific data points (price, change, volume, etc.). It distinguishes from siblings like bse_quote by specifying NSE.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for NSE stock quotes) but does not explicitly guide when not to use or contrast with siblings like live_quote, stock_quote, or bse_quote.
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 explains what the tool returns (today's performance with best/worst), but does not disclose caching, real-time vs daily data, or any side effects. The description 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: 3 sentences and an example. Every sentence adds value. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema present, the description sufficiently explains what the tool does. It lists the sectors and confirms it shows today's performance. Could mention time frame more explicitly, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so baseline is 4. The description states 'No arguments needed' which adds clarity. No further parameter value is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get performance of Nifty sectoral indices' and lists the specific sectors. It also mentions best/worst performers, and includes an example. This is precise and distinct from siblings like get_sector_peer_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'No arguments needed' which is useful, but it does not provide guidance on when to use this tool versus other sector-related siblings (e.g., get_sector_peer_context). No explicit when-not-to-use or alternative tool mention.
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 full responsibility for behavioral disclosure. It mentions that the AUM data is 'approximate' and that data is monthly, which provides some insight, but lacks details on rate limits, authentication needs, or 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, with a clear list of provided data and a relevant pricing note. It is front-loaded with the core purpose. However, the pricing information could be considered slightly tangential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero input parameters and the presence of an output schema, the description adequately covers the main outputs (AUM, SIP flows, folios, scheme breakdown). It does not repeat the output schema but adds context about data sources and approximation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description adds meaning by explaining what the tool returns, which goes beyond the empty schema. According to guidelines, 0 parameters gets a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides AMFI mutual fund industry data, including specific data points like total AUM, SIP flows, and scheme counts by category. It distinguishes itself from sibling tools by focusing on industry-level aggregate data, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by mentioning that similar data costs $17,500/year from Morningstar Direct, implying this tool offers a free alternative. However, it does not explicitly state when to use this tool versus alternatives, nor provide 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?
No annotations are provided, so the description carries full burden. It clearly states it returns live price, 24h change, market cap, volume, and all-time high. It implies a read-only, real-time operation. However, it does not disclose potential rate limits, data freshness guarantees, or authentication needs, which would elevate it to a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise: one sentence for purpose, one line for returned fields, and a brief args section with examples. It is front-loaded with key information. However, the three example lines could be condensed into a single sentence, making it slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema (mentioned in context signals but not displayed), the description adequately covers the use case. It lists key return fields and gives usage examples. It is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required string parameter 'symbol' with 0% description coverage. The description compensates well by explaining it is a crypto ticker and providing explicit examples (BTC, ETH, SOL, etc.), clarifying the expected format. This adds meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get live cryptocurrency price in USD' with a specific verb and resource. The list of returned fields (price, 24h change, market cap, etc.) and the examples differentiate it from sibling tools like crypto_historical 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of typical symbols (BTC, ETH, SOL) but does not explicitly state when to use this tool versus alternatives (e.g., crypto_historical for historical data). Usage is implied through context, but no direct guidance on when-not-to-use 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?
With no annotations, the description carries the burden. It discloses 'zero delay when configured' as a behavioral trait, lists returned fields, and implies a read-only operation. However, it doesn't mention error behavior or data freshness guarantees beyond zero delay.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a purpose sentence, output list, setup instructions, and parameter details. The setup section is slightly detailed but may be extraneous if the environment is already configured. Overall, no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description covers main return fields and setup. It lacks information on error handling, rate limits, or symbol validation, but for a simple live quote tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides parameter meaning: 'symbol: NSE symbol (e.g. RELIANCE, TCS, INFY)'. This adds clarity beyond the schema's type-only definition, though it could include more examples or accepted formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'real-time NSE stock quote via Fyers API v3' with specific output fields (LTP, O/H/L/C, volume, change%, 52W high/low). It distinguishes from siblings by specifying the Fyers API source, which sets it apart from other live 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for NSE stocks via Fyers but does not explicitly state when to use this tool versus alternatives (e.g., nse_quote, bse_quote). No guidance on when not to use or prerequisites beyond setup credentials.
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 provided, so description must cover behavioral traits. It lists what the tool shows but does not disclose data source, update frequency, or any side effects. For a read-only tool, this is adequate but could be more 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, uses bullet points effectively, and includes example usage. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and output schema present, description adequately covers inputs and outputs. However, it could briefly explain the output structure (e.g., JSON fields) for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds 'NSE symbol' and examples (RELIANCE, HDFCBANK, INFY). This provides essential meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Sector and peer context for a stock' and lists specific outputs (peer basket, rank, valuation, sector context). This distinguishes it from siblings like sector_performance (overall sector) and compare_stocks_tool (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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for obtaining peer and sector context, but does not explicitly state when to avoid or provide alternatives. Context is clear but lacks explicit guidance on 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?
No annotations provided, so description carries the full burden. It discloses return values (LTP, O/H/L, previous close, volume, change%), real-time nature, and setup requirements including authentication and daily session token refresh. Missing details on rate limits or error handling, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, return values, and setup instructions. The setup information is lengthy but still front-loaded. Some text could be considered extraneous for a tool description, but it remains efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values are covered. The description provides sufficient behavioral context for a single-parameter real-time quote tool with authentication needs. Sibling tools are many, but the name and description make its niche clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'symbol' with 0% schema description coverage. The description compensates by specifying it expects an NSE symbol and provides examples (RELIANCE, TCS). This adds meaningful context beyond the schema's bare name. Could be improved by noting case sensitivity or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Real-time NSE quote via ICICI Breeze API' and specifies 'zero delay when configured'. The tool name 'icici_live_quote' together with the description distinguishes it from siblings like nse_quote and fyers_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for NSE real-time quotes via ICICI, but does not mention when not to use it or point to sibling tools like nse_quote or bse_quote.
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 lists input signals and risk levels but omits details on read-only nature, rate limits, or side effects, providing adequate but incomplete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections (purpose, signals, risk levels, param), no wasted words, and front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers all necessary aspects: what it does, what it returns (risk levels), and appropriate usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to the single parameter 'symbol' beyond the schema, specifying it's an NSE symbol and suggesting suitability for mid/small caps, compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool predicts lower circuit risk for NSE stocks, uses specific verb 'predict', and distinguishes from siblings like 'nse_circuit_breakers' by focusing on risk assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'most useful for mid/small caps under stress', providing context but no explicit when-to-use or alternatives, leaving ambiguity for agents.
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?
Given no annotations, the description discloses that it returns OHLCV data with summary stats. It does not detail error handling or rate limits, but the output schema likely covers return structure. Transparent enough 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with front-loaded purpose, structured Args section, and clear examples. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers purpose, parameters, and examples adequately. Could mention data source or update latency, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides complete parameter documentation (symbol, period, interval with valid values) and examples, compensating for the 0% schema description coverage. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves historical price data for any global stock and returns OHLCV data with summary stats. This distinguishes it from sibling tools like nse_historical (only Indian) or stock_quote (current price).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., nse_historical for Indian stocks, crypto_historical for crypto). The examples show usage but do not specify exclusions or context.
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 the data source (Finance Ministry, public) and leading indicator behavior, but does not explicitly confirm it is read-only or describe any limitations like data freshness or accuracy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with no wasted words. It front-loads the core concept, provides an example, and clearly separates sections for sectors and args.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values need not be described) and only one parameter, the description covers the tool's purpose, usage, and sector scope adequately. Minor gaps include lack of detail on the prediction methodology or confidence intervals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'sector' lacks schema descriptions (0% coverage), but the description compensates by listing valid sector values (Auto, FMCG, etc.) and explaining the 'all' option for a full report. This adds significant meaning beyond the schema's default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool correlates GST data to sector performance as a leading indicator, with a concrete example ('GST from auto sector up 24% YoY → MSIL/Bajaj Auto historically follow in 2-3 months'). It distinguishes itself from sibling tools like sector_performance by specifying its predictive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for leading indicators based on GST data) and lists covered sectors. However, it does not explicitly state when not to use it or mention alternative tools, leaving some ambiguity.
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 provided, so description carries full burden. It mentions data source (SEBI filings) and output fields, but omits details on data freshness, rate limits, error handling, or confirmation that it's read-only. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, context, output list, args, and examples. It front-loads the core function. Some marketing language about Bloomberg pricing is non-essential but not harmful. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the main use case and output fields. It lacks notes on error cases or data limits, but the presence of an output schema reduces the burden. Reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains the 'symbol' parameter with examples (RELIANCE, TATAMOTORS, ADANIENT) and context (NSE stock symbol). 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves credit ratings for Indian listed companies from SEBI-mandated filings. It specifies the resource (credit ratings), context (Indian, SEBI), and distinguishes from sibling tools that deal with other financial 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (need credit ratings, especially free alternative to Bloomberg) but does not explicitly contrast with siblings like company_profile or nse_quote that might also offer rating data. It provides clear context but lacks direct 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 provided, so the description carries the full burden. It discloses outputs (action, confidence, strike zone, factors, risk flags) but does not mention data freshness, fallbacks, or any potential side effects. Sufficient but could be more 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences front-loaded with purpose, followed by output details. Generally concise but could tighten phrasing. No unnecessary words, but one or two sentences could be combined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter with default and an output schema, the description fully explains what the tool returns (action, confidence_pct, strike zone, approve_message, factors, risk flags). Appropriate for a decision support tool with limited parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'symbol' with default 'NIFTY'. Schema description coverage is 0%, but the tool description explicitly states it works for 'NIFTY / BANKNIFTY', implying the parameter accepts these values. This adds meaning beyond the schema, though it could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an options setup for NIFTY/BANKNIFTY intraday decisions. It specifies the verb 'build', the resource 'options setup', and the scope (intraday, NIFTY/BANKNIFTY). It lists included indicators and outputs, making it distinct from sibling tools which focus on 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for intraday options decisions on NIFTY/BANKNIFTY. It lacks explicit when-not-to-use or alternative tools, but the context is clear. No explicit exclusions or comparisons to siblings.
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 burden. It transparently states the data source (public AMFI disclosures), lists supported funds, and describes the output fields. However, it does not disclose potential delays, data freshness, or any limitations (e.g., only Indian funds). Overall, it provides solid 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with purpose. It includes a useful example and clearly structured argument information. It could be slightly more concise, but overall it is effective and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema, the description appropriately details return values (overlap_pct, common_stocks, etc.) without redundancy. It covers the main functionality but could mention error handling or unsupported fund cases. Overall, it is sufficiently complete for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines two string parameters with no descriptions (0% coverage). The description compensates fully by providing concrete examples (e.g., 'HDFC Flexi Cap') and listing supported fund names, which is critical for correct invocation. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Mutual fund overlap analyzer' using public AMFI disclosures, with a specific verb ('analyzes') and resource ('overlap between mutual funds'). It lists supported funds and what it returns, distinguishing it from sibling tools like portfolio_analysis or mutual_fund_nav.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example of when to use the tool (checking diversification with an overlap example), but does not explicitly contrast it with alternative tools or state when not to use it. The usage context is implied but lacks explicit guidance on selection among siblings.
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, but the description explains the tool's logic (checks pledge % and QoQ change), defines risk levels, and describes the return fields. It adds context about the margin call risk. However, it does not explicitly state it is a read-only 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative with sections for purpose, risk levels, example, and returns. It is slightly verbose but each sentence adds value and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no annotations, the description covers purpose, parameters, return fields, and risk context. It is complete enough for an agent to invoke correctly, though it lacks mention of error handling or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'symbol' is described as 'NSE symbol (e.g. ADANIENT, ZEEL, any stock)', which adds meaning beyond the schema's title. With 0% schema description coverage, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Promoter pledge early warning for an NSE stock' and explains it checks pledge percentage and QoQ change velocity, with defined risk levels. This differentiates it from siblings like 'promoter_pledge' (raw data) and 'scan_pledge_risks' (scanning multiple stocks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single stock early warning but does not explicitly state when to use this versus siblings like 'promoter_pledge' or 'scan_pledge_risks'. No when-not-to guidance is provided.
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 fully discloses the behavior: it runs 6 expert personas, returns consensus and debate data, and uses Indian market data. It does not mention rate limits or auth, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for agents and clear Args/Returns sections. It is somewhat lengthy but every sentence adds value. Front-loaded with the core concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers the return structure. It lacks details on error handling or edge cases, but for a simple parameter tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explicitly explains the single parameter 'symbol' with examples (e.g., RELIANCE, TCS, HDFCBANK), adding full meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a multi-agent AI stock brief with 6 personas debating BUY, HOLD, or SELL, using real Indian market data. This distinctively separates it from siblings like get_stock_debate 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a consensus from multiple perspectives is desired, but does not explicitly state when to use this tool versus alternatives like get_stock_debate or get_nifty_outlook. No when-not conditions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the full 3-round process, agent interactions, and all return fields (rounds, debate_edges, minds_changed, final_consensus). No annotations, but description carries the burden well, though it omits prerequisites or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and section headers. Front-loaded with purpose. Every sentence adds value, no fluff. Appropriate length for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all major aspects: rounds, influence graph, consensus. Mentions visualization use case. Lacks error details or preconditions, but for a debate tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'symbol' has 0% schema description coverage, but the description adds examples and clarifies it's an NSE symbol. Adds some value beyond the schema, but not extensive detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states '3-round sequential debate' and distinguishes from sibling get_stock_brief. Uses specific verb 'runs a live debate' and describes resource (stock symbol) with detailed round mechanics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with get_stock_brief (parallel analysis) and advises watching for minds_changed to identify complex setups. Could be more explicit about when not to use, but provides clear context.
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 for behavioral disclosure. It mentions the tool is free and provides links to live sources, but does not discuss rate limits, data freshness, or any constraints. It also does not describe what happens if data is unavailable. Adequate but leaves important behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence, a note about cost, a bullet list of outputs, and an example. It is somewhat lengthy but every sentence adds value. Could be slightly more concise, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description covers all necessary aspects: what data is returned (Nifty close/change, global indices, status, links) and the context (pre-market, free). It is complete for a data retrieval tool with no inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information because there are none, which is acceptable. No schema detail beyond the empty schema is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides GIFT Nifty pre-market data and overnight global indices for Indian market preview. It lists specific outputs: Nifty 50 close/change, global indices (S&P 500, Dow, NASDAQ, Hang Seng), market status, and links. This distinguishes it from siblings like nifty_index (which likely provides only Nifty data) and nse_market_status (which only shows NSE 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pre-market analysis by mentioning 'pre-market data' and 'overnight global indices'. It also notes that Bloomberg charges for similar data, positioning this tool as a free alternative. However, it does not explicitly state when to avoid using this tool or name specific alternatives among the many sibling tools, which would strengthen 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 returned data categories, parameter effects (quarterly vs. annual), and includes examples illustrating the output structure. It does not mention limitations like data range or rate limits, but the disclosure is sufficient given the tool's 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-organized with sections for overview, args, and examples. Every sentence adds value, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but present), the description complements it by listing typical line items. It covers the tool's capabilities, parameters, and usage examples, making it complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains both parameters: symbol (stock ticker with examples) and quarterly (boolean for quarterly/annual data) with examples. This adds complete meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves an income statement (P&L) and lists key line items. It does not explicitly distinguish from sibling tools like balance_sheet or cash_flow, but the name and content make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and states compatibility with Indian and US stocks, giving implicit usage context. However, it does not specify when to prefer this tool over siblings 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 details the outputs: PCR by expiry, overall sentiment, and OI data. It clearly indicates it's a read-only data retrieval tool. However, it could mention potential limitations like data freshness 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, list of outputs, args, and examples. It is slightly verbose but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to detail return format. It adequately covers purpose, parameters, and usage examples. Missing detail on data update frequency or limitations, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description fully explains the only parameter 'num_expiries' with its default value and purpose. This compensates completely for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calculates Nifty PCR trend across multiple expiries as a market sentiment gauge, which is a specific verb+resource. It distinguishes itself from siblings, as no other tool computes PCR trend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's a free alternative to Sensibull Pro, but does not explicitly state when to use or avoid this tool versus alternatives. Examples are provided but without exclusive conditions.
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 reveals the scope (Nifty 500) and the circuit_type parameter, but lacks details on data freshness (live vs. historical), read-only nature, or any rate limits. Basic behavioral context is given, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a docstring format including Args and Examples. It is concise but includes essential information; a bit more trimming could be done, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers the core functionality, scope, and parameter. Minor missing details like data source or refresh cadence, but adequate for a simple scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description fully explains the single parameter circuit_type with its allowed values ('upper', 'lower', 'both') and provides 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans NSE stocks hitting upper or lower circuit limits, specifying the scope as Nifty 500. It distinguishes from siblings like nse_52week_scanner and predict_circuit by focusing specifically on circuit breakers, and includes parameter details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to get stocks at circuit limits) and provides examples for each circuit_type. However, it does not explicitly state when not to use it or mention alternative tools like predict_circuit.
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 provided, so description bears full burden. It indicates the tool retrieves data (read-only) but does not disclose potential limits on history depth, rate limits, or any side effects. Basic transparency is met but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, with two short paragraphs: one for purpose and one for parameter details. It is front-loaded with key information, no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param) and presence of an output schema, description adequately covers purpose, parameter, and examples. It is complete for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one required string parameter 'symbol' with 0% coverage. Description adds concrete examples (e.g., ITC, RELIANCE) and explains it is an NSE stock symbol, greatly enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and clearly identifies resource 'corporate actions for an NSE stock', listing examples like dividends, stock splits, bonuses. It effectively distinguishes from siblings like dividend_history by covering broader corporate actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and mentions scope (recent and historical with dates and values), but does not explicitly state when to use this tool versus alternatives like dividend_history or nse_quarterly_results. It lacks guidance on 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the tool provides analysis results (P&L, weights, risk) but does not explicitly state if it is read-only or if there are side effects. The presence of an output schema helps, but further details on data sources or limitations 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, parameter documentation, and examples. It is front-loaded with the purpose. While slightly lengthy, it avoids unnecessary information and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description covers the core functionality and usage. Minor gaps exist, such as error handling or limits on holdings size, but overall it is sufficient for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter with zero description coverage, but the tool description includes a detailed explanation of the 'holdings' parameter, including format, required fields, and an example. This fully compensates for the schema's lack of param documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes a stock portfolio, covering P&L, weights, risk, winners, and losers. It uses specific verbs and resources, and the PRO tag distinguishes it from free tools. Among siblings, there is an 'analyze_portfolio' tool, but this description provides enough detail to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool with examples and parameter requirements. However, it does not explicitly state when to use this tool versus alternatives like 'analyze_portfolio' or 'backtest_strategy', leaving some ambiguity.
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 disclose behavior. It states the return type (links to EDGAR) but does not mention edge cases (e.g., invalid ticker), rate limits, or pagination. This is adequate but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary, labeled arguments, and examples. It is concise but could be tightened by removing redundant statements (e.g., 'Returns links...' could be merged).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameters, and provides examples. Given that an output schema exists (implied), it need not detail return values beyond stating the type. Minor omissions (e.g., error handling) do not significantly impact completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description lists all three parameters with explanations, examples, defaults, and options. This adds significant meaning beyond the raw schema, making it highly useful for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves SEC filings for a US-listed company and returns links to documents on EDGAR, specifying the resource and action. It distinguishes from sibling tools like 'sec_filing_search' by focusing on known tickers and filing types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear parameter explanations and examples that imply usage scenarios (e.g., retrieving annual or quarterly reports). It does not explicitly contrast with alternatives like 'sec_filing_search', but the context is sufficient for an agent to decide when to use this tool.
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 security-relevant behavior (API key stays in local .env, never committed) and explains it shows status and instructions. However, it does not detail return values or error handling, which might be covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear front-loaded purpose sentence. The security note and example add value without unnecessary length. It earns its place but could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description adequately covers the tool's functionality and adds security context. It is complete for a simple status check tool, though it could mention output specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter semantics. The schema coverage is 100% trivially. The description adds context about the tool's purpose and security, which is valuable beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check Angel One SmartAPI integration status and get setup instructions', which is a specific verb-resource pair. It explicitly names 'Angel One', distinguishing it from sibling broker status tools like fyers_status and icici_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool: to check if Angel One credentials are configured and working, and to get setup instructions. It provides clear context but does not explicitly state when not to use or list alternatives, though the sibling tools suggest other brokers.
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 provided, so the description carries the burden. It describes a read-only operation returning a comparison table, which is adequate but does not mention any specific behaviors beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a header, list of metrics, and examples. Slightly verbose but still concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the output fields, parameter usage, and examples. Given the tool's simplicity and the presence of an output schema, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'symbols' is explained with format (comma-separated, 2-5 stocks) and examples, adding 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares 2-5 stocks side by side and lists specific financial metrics displayed, distinguishing it from other stock-related tools like stock_screener or company_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for side-by-side comparison) and provides examples, but lacks explicit guidance on when not to use or alternatives.
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?
The verb 'view' implies read-only, but without annotations, the description does not explicitly state non-destructive behavior or potential side effects like rate limits or data latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a brief purpose, row format description, usage advice, and arg list. A minor improvement could be merging the first two sentences for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers tool behavior, argument details, and usage context. No gaps for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully compensates by explaining both parameters: symbol (NSE symbol or empty string for all) and limit (default 20, max 100), adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves recent signals with actual outcomes, distinguishing from sibling tools like check_signal_outcomes and get_signal_accuracy by focusing on logged history and outcome labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: audit the model, build trust, export. However, it does not mention when not to use this tool or explicitly name alternatives among siblings.
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, the description fully discloses behavioral traits: requires Angel One API credentials stored locally, real-time zero-delay data, graceful fallback, and the full set of returned fields (OHLC, volume, circuit limits, etc.). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured with a summary line, bullet points for features, setup steps, and examples. It is slightly verbose but every section adds value; no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, required credentials, fallback behavior, data fields, and examples. While no formal output schema is referenced, the list of provided fields suffices. It lacks explicit mention of pagination or rate limits, but for a single-parameter quote tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'symbol', is described as 'NSE symbol (e.g., RELIANCE, TCS, NIFTY, BANKNIFTY)', providing concrete examples and implying support for both stocks and indices. This adds meaning beyond the schema's type and title, though the schema has 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides real-time NSE quotes via Angel One SmartAPI, explicitly listing the data fields (LTP, OHLC, volume, etc.). It distinguishes itself from sibling tools like bse_quote, nse_quote, and fyers_live_quote by specifying the broker and real-time nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides setup instructions and notes that it falls back gracefully with guidance. It compares pricing with Zerodha. However, it does not explicitly advise when to use this over other quote tools in the sibling list (e.g., bse_quote, fyers_live_quote), leaving the agent to infer based on broker preference.
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?
The description discloses that it shows large transactions exceeding 0.5% of shares, but does not mention data freshness, delays, or other behavioral aspects. Given no annotations, it carries the full burden but only partially meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: four lines including an example. It front-loads the purpose and uses bullet-style formatting for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no annotations, the description covers the essential: what it does, the threshold, and an example. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description confirms 'No arguments needed' and provides an example call, which adds clarity beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves recent bulk and block deals, specifying the threshold of 0.5% of total shares. This distinguishes it from other NSE tools that provide different data or timeframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'No arguments needed' and provides an example. It also mentions utility for tracking institutional activity. While it doesn't compare directly with siblings, the context is sufficient for a zero-argument 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?
The description mentions the data is for today and includes interpretation hints (FII net buy = bullish). However, it does not disclose data freshness, source, or potential limitations (e.g., only available when market is open). No annotations are provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences plus a one-line example. It front-loads the core action and immediately adds value with interpretation and usage example. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description provides sufficient context: what data is returned, how to interpret it, and a concrete example. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty with 100% coverage. The description reinforces that no arguments are needed, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves FII and DII activity data, including net buy/sell amounts and their market signals. It distinguishes itself from sibling tools by focusing specifically on institutional daily flow 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'No arguments needed' and provides an example call. While it implies usage for today's activity, it does not explicitly contrast with alternatives like amfi_fund_flows or nse_bulk_deals, which are sibling tools for different data.
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 provided, so description carries burden. Discloses that 1m data only available for last 7 days. Does not mention adjustment policies, rate limits, or error behavior, but adds meaningful constraint beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-paragraph structure with examples. No redundant sentences. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters and constraints. Output schema exists so return details not needed. Lacks error handling info but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0% but description fully explains all three parameters: symbol (with examples), period (lists options), interval (lists options and restriction). Examples provide concrete usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get historical price data (OHLCV) for an NSE stock'. Distinguishes from siblings like stock_historical (generic) and nse_quote (current price). Examples reinforce 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples imply use cases but no explicit when-to-use vs alternatives. Sibling tools like stock_historical or crypto_historical exist without differentiation in description.
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 details what the tool returns (call/put options with specific fields) but omits behavioral traits like data freshness, rate limits, or read-only nature. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, with a brief intro, bullet-style field list, args section, and examples. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description sufficiently explains inputs, outputs, and usage via examples. It doesn't need to detail return values since output schema exists. Complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (symbol) has 0% schema description coverage, but the description provides examples of valid values (e.g., RELIANCE, NIFTY) and clarifies it covers stocks and indices. This adds meaning beyond the schema's raw type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves options chain data for NSE stocks or indices, listing specific fields like strike price, premium, volume, OI, IV, and PCR. Examples with common symbols (RELIANCE, NIFTY) reinforce the purpose. This distinguishes it from sibling tools that focus on quotes, historical data, or other 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for options chain data but lacks explicit guidance on when to use versus alternatives or when not to use. No exclusions or prerequisites are stated, though the specific purpose makes context 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?
No annotations exist. The description does not disclose behavioral details such as authentication, rate limits, or data freshness. It only covers the basic function, missing opportunities to add transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a clear structure with Args and Examples sections. Every sentence is informative and necessary, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-driven tool, the description covers the purpose, parameter options, and usage examples. An output schema exists, so return values need not be detailed. It is fully adequate 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with no description. The tool description compensates by explaining the three valid values for mover_type and provides examples, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves today's top performing stocks on NSE, specifically the top 10 by criteria from Nifty 50 components. It distinguishes itself from sibling tools like nse_quote or nse_52week_scanner by focusing on daily movers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three mover types (gainers, losers, active) and when to use each. It does not mention when not to use or alternatives, but it provides sufficient context for correct invocation.
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 full burden. It discloses the four signals used, the outputs (beat_probability_pct, signal, key_risks, etc.), and the data source (yFinance). Missing limitations or reliability notes, but overall 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically structured (purpose, signals, returns, viral use, args) and mostly concise. The 'viral use' section adds length but is not essential, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (predictive model with 4 signals) and an output schema that details returns, the description adequately covers purpose, inputs, and outputs. It lacks explanation of the model's reliability or calculation method, but remains fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter 'symbol' with 0% description coverage. The description compensates by stating 'NSE symbol' and providing examples (TCS, INFY, etc.), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool predicts earnings outcomes before quarterly results using a specific verb ('predict') and resource ('earnings'). It distinguishes itself from sibling tools like 'earnings_calendar' and 'nse_quarterly_results' by being a predictive AI model, not just data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context (e.g., 'Viral use: post prediction before TCS/Infy results') and explains it combines 4 signals, implying when it is useful. However, it does not explicitly state when not to use it or compare it to alternative tools like 'earnings_calendar'.
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 explains the strategy logic (cross conditions) and compares to buy-and-hold. Since no annotations exist, it adequately covers behavior. The presence of an output schema reduces the need to describe return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (PRO tag, strategy, args, examples) and is informative without being excessively long. Minor redundancy (repeating defaults in examples) could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the strategy, parameters, and examples adequately. It might benefit from mentioning data prerequisites or output format, but the output schema exists. Overall complete for a backtesting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by listing and explaining all five parameters, including defaults and examples (e.g., symbol, short_window, long_window, period, initial_capital).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: backtesting a Simple Moving Average (SMA) crossover strategy. It uses specific verbs and resources, distinguishing it from the many 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context and examples, showing when to use this tool for SMA crossover backtesting. However, it does not explicitly mention when not to use it or suggest alternative 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 bears full responsibility for behavioral disclosure. It details the signal logic, data source (quarterly NSE shareholding), and return fields including divergence_type, signal, confidence, interpretation, historical_implication, and raw data. It does not mention any side effects or rate limits, but as a read-only analytical tool, the description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections: introduction, signal conditions, example quote, data source, and args/returns. While it includes an illustrative example, it is not overly verbose. It front-loads the main use case effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the description covers the tool's purpose, behavior, input format, and output details comprehensively. The presence of an output schema is noted, but the description still explains the return structure, making the tool fully understandable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly defines the 'symbol' parameter as an NSE symbol and provides examples (HDFCBANK, RELIANCE, TATAMOTORS). This adds meaningful context beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it detects 'FII vs retail divergence' and describes it as the 'highest-conviction signal in Indian markets'. It uses a specific verb 'Detect' and clearly distinguishes the resource (FII and retail divergence on stocks). Among siblings, this is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: for detecting divergence between FII and retail actions. It provides a concrete example with HDFC Bank and mentions the data source (public NSE shareholding disclosures). However, it does not explicitly state when not to use it or mention alternative 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 provided; description explains scraping, classification, signal generation, and fallback behavior. Does not discuss rate limits or potential errors, but covers main behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded summary, but includes lengthy setup instructions; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input, output, fallback, and setup. Lacks details on error handling or invalid inputs, but overall sufficient 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains symbol as NSE stock symbol and limit with default 100 and max 200, adding significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it analyzes social media sentiment for NSE stocks using Reddit and Twitter, specifies subreddits and fallback, and distinguishes from siblings like market_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for sentiment analysis but lacks explicit when-to-use alternatives. Mentions fallback to yFinance if social APIs not configured, providing context.
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. It discloses the tool's read-only nature, data sources, and output contents (signal zones, history). It does not mention rate limits or authentication, but the scope is appropriately transparent for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet complete, with a clear summary, bullet-pointed outputs, parameter definition, and examples. Every sentence serves a purpose without redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential behavioral aspects. The bulleted outputs and interpretation guide provide sufficient context for an agent to understand the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the sole parameter 'days' as lookback period with default, compensating for the 0% schema description coverage. This adds meaningful context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves India VIX data, including current level, change, signal zones, history, and interpretation. It distinguishes itself from sibling tools like nifty_index or india_macro_indicators by focusing specifically on the volatility 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on data source (NSE free, Trendlyne charges) and usage examples. It does not explicitly contrast with alternatives, but the specialization makes it clear when to use this 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?
No annotations are provided, so the description must cover behavioral traits. It states the return fields ('price, change, volume, market cap, P/E, sector, country, and more') and that it works for global stocks. However, it doesn't explicitly state that it is a read-only, non-destructive operation or mention any rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief intro, then bullet points for symbol formats, and examples. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's output schema exists (though not shown), the description lists all key return fields and covers global stock coverage sufficiently. It is complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the 'symbol' parameter, but the description provides extensive detail on symbol formats with examples per region, adding 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get real-time stock quote for any global stock.' It specifies the action (get), the resource (stock quote), and the scope (global). This distinguishes it from siblings like nse_quote, bse_quote, and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit examples for different regional formats (US, UK, Japan, Hong Kong, India) and mentions an alternative for Indian stocks ('use nse_quote for Indian stocks'). While it doesn't exhaustively list all alternatives, it gives clear usage context.
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 clearly explains the tool's screening behavior, including criteria and exchange options. However, it does not address potential side effects, authentication, or rate limits, which are minor given the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, parameter list, and examples, all front-loaded. Every sentence is useful, and the examples are concise yet illustrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description focuses on inputs and usage. It covers all 9 parameters across two exchanges, includes examples, and provides sufficient detail for effective use without superfluous information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates fully with detailed explanations for each parameter, including examples, defaults, and usage hints like 'e.g., 15 for value stocks', adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Screen stocks by multiple financial criteria' and lists specific filters (P/E, ROE, etc.) and exchanges (Nifty 50, S&P 500), making the purpose clear and distinct from siblings like 'nse_52week_scanner' or 'scan_watchlist'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples illustrating typical usage but lacks explicit guidance on when to use this tool versus alternatives (e.g., technical scanners). Usage is implied by the parameter-focused examples.
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 provided, so description carries burden. It details calculation rules including capital loss carry forward, but doesn't explicitly state it has no side effects. Still sufficiently 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with overview, rules, args, returns, examples. Front-loaded purpose. Could be slightly more concise, but each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for the tool's complexity: covers all required and optional parameters, explains return value format, includes examples. Output schema exists but description still provides adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description includes an Args section with explanations for all parameters, including optional ones like symbol and asset_type. Provides format, default, and examples, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it calculates Indian LTCG/STCG tax liability for equity/mutual fund trades, with specific tax rules. Unambiguous and distinct from 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly indicates applicable tax rules (post July 2024 Budget) and asset types. While it doesn't list alternatives, the specialized nature makes usage 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?
No annotations provided, so description bears full burden. It details the four signals and output format (alert level, verdict, alerts, findings), making behavior transparent. Does not mention permissions or side effects, but as a read-only monitoring 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points listing the four signals, an example output, and clear sections for args and returns. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given 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), the description adequately explains return fields. The tool is standalone and the description covers all essential aspects: inputs, signals, output, and example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (symbol) with 0% schema description coverage. The description adds examples (e.g., RELIANCE, HDFC) and clarifies it is an NSE stock symbol, compensating for schema lack.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it detects smart money and unusual activity for NSE stocks by scanning four specific signals. It is distinct from sibling tools like nse_insider_trading or nse_bulk_deals which cover only individual aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to detect unusual activity) but does not explicitly state when not to use or mention alternative tools. However, it provides clear context for its composite nature.
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 explains that the tool aggregates multiple data points into one call, which is transparent about its behavior. It does not mention any side effects or permissions, but for a read-only data retrieval tool, this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and uses a bullet list for clarity. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and a well-defined purpose (morning F&O brief), the description is complete. It covers all major return components, and an output schema exists for additional detail, though not provided here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (empty properties), so schema coverage is 100%. The description adds meaning by detailing what the tool returns, fulfilling the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an 'F&O-focused morning brief for NIFTY and BANKNIFTY traders' and enumerates the specific sections it compiles (GIFT Nifty, India VIX, etc.). This distinguishes it from sibling tools like 'get_morning_brief' and 'get_nifty_outlook'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is intended for morning preparations for F&O trading by listing its contents, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The context is clear enough for an informed agent.
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?
Explains how signals are logged and checked after 7 days. Discloses return fields (accuracy %, avg return, breakdown). No annotations provided, so description carries burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose first, then mechanism, use cases, args, returns. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, mechanism, use cases, param details, and return values. Output schema exists, so return details are sufficient. All aspects addressed for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to all 3 parameters (source filters with allowed values, symbol as NSE, days as look-back). Schema has 0% coverage, so description compensates effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool shows accuracy of FinStack signals backed by real outcome data. Differentiates from siblings like get_signal_history by focusing on accuracy metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (prove accuracy, compare sources, find best stocks). Lacks explicit when-not-to-use or alternatives, but 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?
Describes return value: up to 10 recent articles with title, publisher, link. No annotations, but description adequately conveys read-only behavior and output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence purpose, followed by clear args documentation and examples. No redundant information, front-loaded with key action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param tool with an output schema, the description covers purpose, parameter semantics, usage examples, and return format. Complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains the symbol parameter's purpose, optionality, and default behavior (empty for general news). Adds meaning beyond the schema's basic type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the latest market news for a stock or general market, with specific verb and resource. It distinguishes from sibling tools focused on quotes, fundamentals, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: optional symbol for company news, empty for general. Examples illustrate usage. No explicit alternatives, but context is sufficient given the tool's unique role among siblings.
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 states the tool returns market status, hours, and time. It doesn't disclose potential side effects or rate limits, but as a read-only query, this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences, including an example. It is front-loaded with the purpose and has no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and a simple purpose, the description is complete. It mentions return values and provides an example. An output schema exists, but the description already covers the key return info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description does not need to add parameter info. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'if the Indian stock market (NSE/BSE) is currently open or closed.' It specifies the return values (market status, trading hours, IST time) and is distinct from sibling tools like 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates no arguments needed and provides an example. It implicitly tells when to use it (to check market status). While it doesn't explicitly mention alternatives, the purpose is unique among siblings.
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?
Without annotations, the description carries full burden. It discloses that the tool scans multiple stocks simultaneously and returns sorted results, implying a read-only operation. This is sufficient, though it could mention that no data is modified or provide more detail on risk criteria.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences plus an args section, all front-loaded with key information. Every sentence adds value: purpose, behavior, usage, and parameter details. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description need not detail return values. It covers what the tool does, how to use it, and an example parameter. For a simple scan tool, this is complete and sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides an example and clarifies that symbols are NSE symbols (e.g., 'ADANIENT'), adding meaning beyond the schema's type-only definition. This helps the agent understand parameter format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans multiple NSE stocks for promoter pledge risk simultaneously, which distinguishes it from sibling tools like 'promoter_pledge' that may handle single stocks. The verb 'scan' and resource 'promoter pledge risk' are specific, and sorting by risk level is mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case: 'useful for screening your watchlist or Nifty 500 for pledge dangers.' However, it does not explicitly state when not to use this tool or mention alternatives, such as single-stock pledge tools, leaving some ambiguity for the agent.
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?
Description reveals output (CIK number and filing page link) but lacks detail on side effects, network calls, or error conditions. No annotations provided, so transparency could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (4 sentences plus examples), front-loaded with purpose, and every sentence adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with output schema, description covers purpose, parameter, and output summary with examples. Lacks error handling or edge case details, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema defines symbol as string with no description. Description adds 'US stock ticker (e.g., AAPL, MSFT, GOOGL)', providing crucial context. Schema coverage is 0% so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states purpose: 'Search SEC EDGAR for a company and get their filing page.' It distinguishes from sibling tool sec_filing by directing users to that tool for specific 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly tells when to use this tool (to get company filings page) and when to use sec_filing for specific documents. Also specifies argument as US stock ticker.
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?
The description lists criteria scanned (volume spike, price surge, etc.), expected output (pump_probability, red_flags, verdict+recommendation), and includes a realistic example. This fully compensates for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, scan criteria, example, returns, and args. It is front-loaded with the key action. However, the inclusion of a quote and example adds some verbosity that could be trimmed for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema (implied by 'Returns'), the description covers input, analysis logic, and output fields thoroughly. No critical gaps remain given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by specifying 'NSE symbol (most useful for small/micro caps)', providing context beyond the schema's bare 'string' type. It could further specify format (e.g., 'RELIANCE') but is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Detect pump-and-dump operator activity in an NSE stock' which is a specific verb+resource. It uniquely identifies the tool's purpose among many sibling tools, as no other tool explicitly targets pump-and-dump detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when the tool is most applicable by noting 'most useful for small/micro caps' in the args section. However, it does not explicitly compare to siblings or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it returns top 5 bid/ask prices and quantities, total queue size, and is real-time. No annotations exist, so description carries the burden; it covers essential traits without mentioning failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with key purpose, then context, then parameter explanation, and example. Every sentence adds value; structure is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema visible, the description explains the output structure (top 5 buy/sell orders, total queue size). Covers setup, source, and parameter. Output schema exists for further detail, making this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description details the single parameter 'symbol' with examples and format (NSE symbol). Adds significant meaning beyond the schema's bare 'Symbol' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Level 2 order book depth — top 5 bid/ask prices and quantities', specifying the verb and resource. It distinguishes from sibling tools like live_quote by emphasizing Level 2 depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on source (exchange-licensed), cost (Zerodha/Angel One), and setup (API credentials). It does not explicitly list when not to use or alternatives, but the detail is sufficient for typical use.
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 stand alone. It discloses that the tool searches the AMFI database, requires no API key, and provides NAV, change, and 7-day history. No side effects are expected, and the description is adequately 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, structured with a purpose line, context, args, and examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, output schema present), the description covers all necessary aspects: purpose, input details, usage examples, and output nature. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds crucial meaning: the query can be a fund name or a numeric scheme code. Examples further clarify the usage, fully compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the latest NAV and details for Indian mutual funds, with specific mention of the AMFI database and no API key requirement. It is distinct from siblings like 'amfi_fund_flows'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains input types (fund name or scheme code) with examples. While it does not explicitly state when not to use, the context makes it clear this is for NAV retrieval versus other 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 provided, the description effectively explains the tool's behavior: scanning based on scan_type and threshold_pct. It does not disclose potential rate limits or data freshness, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a brief introductory paragraph, a structured Args section, and clear examples. Every sentence contributes meaning, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description provides sufficient context: purpose, parameter explanations, and usage guidance. It is complete for an AI agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does 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: scan_type (with three options and default) and threshold_pct (with default and meaning). Examples further clarify usage, 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans Nifty 50 stocks near their 52-week high or low, distinguishing it from broader screeners like stock_screener. It uses specific verb+resource ('Scan Nifty 50 stocks') and explains the scan types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use each scan type (momentum vs value opportunities) and includes examples. However, it does not explicitly mention when not to use this tool or suggest alternatives, 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.
Behavior5/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 lists all returned fields (repo rate, reverse repo, etc.) and includes an example output. No side effects are expected, and the data source is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and front-loaded. The Bloomberg mention adds useful context but slightly increases length. It remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given 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 fully explains the return values and usage. It provides examples and covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the description compensates by explaining what the tool returns in detail, adding value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current RBI monetary policy rates (Repo, Reverse Repo, CRR, etc.) and provides an example. It distinguishes from sibling tools by focusing on a specific data set not offered by other 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using this tool for free RBI rates and contrasts with Bloomberg's paid data. However, it does not explicitly list alternative tools or when not to use it. The context is clear enough.
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 provided, so description carries full burden. It discloses that output is sorted and includes top buys/risks, implying a read-only ranking operation. However, it does not detail potential behavioral aspects like API rate limits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear title line, a 'Best use' section, and parameter details. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and presence of output schema, the description fully covers what the tool does, when to use it, what input is needed, and what output is returned. It is contextually complete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds value by specifying that symbols are NSE symbols and providing an example. This clarifies the expected format beyond the generic array type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Batch-rank', the resource 'watchlist', and the method 'FinStack's multi-factor stock signal score'. It distinguishes itself from sibling tools like stock_screener or compare_stocks_tool by focusing on ranking and signal scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Best use' section lists concrete scenarios: daily triage, automation, and finding top buys/risks. This provides clear context for when to use the tool.
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?
Discloses data source (yfinance), output structure (up to 60 entries, annual totals, trailing yield), and examples. No annotations provided, so description carries full burden; could mention rate limits or error handling but 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections (overview, benefits, output list, args, examples). Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes all key outputs (full history, annual totals, trailing yield, total dividends) and includes examples. Output schema exists but description is still thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'symbol' is explained with examples (NSE or global stocks like RELIANCE, TCS, AAPL). Schema has 0% description coverage, but description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides 10-year dividend history with yield calculation and annual summary, listing specific outputs. It distinguishes from sibling 'dividend_history' by being 'deep' and mentioning data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with paid alternatives (Bloomberg/FactSet) and mentions free source (yfinance). Provides usage examples and context for when to use this tool (deep history vs basic).
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:

[![finstack-mcp MCP server](https://glama.ai/mcp/servers/finstacklabs/finstack-mcp/badges/card.svg)](https://glama.ai/mcp/servers/finstacklabs/finstack-mcp)

Score Badge

Copy to your README.md:

[![finstack-mcp MCP server](https://glama.ai/mcp/servers/finstacklabs/finstack-mcp/badges/score.svg)](https://glama.ai/mcp/servers/finstacklabs/finstack-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/finstacklabs/finstack-mcp'

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