Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It adds meaningful constraints: NSE-only symbols, a 15-symbol limit, and a defined set of metrics. It does not disclose output structure, input formatting, or operational details such as rate limits, but for a read-only comparison tool this is a moderate gap rather than a severe one.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence that front-loads the core concept ('side-by-side'), scope ('up to 15 NSE symbols'), and the most important metric categories. There is no filler or redundant repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter, no output schema, and no annotations, the description provides the essential purpose and constraints. It is missing explicit return-format details and routing guidance versus sibling tools, but it gives enough information to make a reasonable first call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It partially does by clarifying that symbols_list refers to NSE symbols and that at most 15 can be supplied. However, it doesn't specify ticker format (e.g., whether to use exchange suffixes like .NS or plain tickers), leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a side-by-side comparison of key metrics for NSE symbols and lists the specific metrics included (valuation, ROE, margins, growth, leverage, dividend yield, 52-week performance, analyst consensus). It is distinguishable from single-symbol siblings like get_key_ratios or get_stock_quote, though it doesn't explicitly name an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'side-by-side' phrasing and 'up to 15 NSE symbols' scope imply the tool is for multi-symbol comparison, giving useful context for when to use it. However, it does not explicitly state when to prefer siblings like screen_stocks or get_key_ratios, nor does it provide exclusion conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the behavioral disclosure. It reveals the 'today (NSE)' time/market scope and the 'which' selection, but does not describe default behavior for the high/low choice, limit handling, sorting, or output format. Adequate for a simple list but with meaningful gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler; the core resource and the key parameter are front-loaded. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential selection and market, but with no output schema and no annotations it omits return shape and limit behavior. Enough for an agent to attempt the call, but not fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It adds meaning to 'which' by specifying high | low, but it never explains 'limit' or how it affects results. Only one of two parameters receives semantic support.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (stocks hitting new 52-week highs/lows on NSE) and the selection parameter (which: high | low). The verb and market scope distinguish it clearly from siblings like get_top_movers or screen_stocks, so an agent can tell what it does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for when to call it: when you need today's NSE 52-week breakout stocks. It does not explicitly name alternatives or exclusion criteria, but the scope is specific enough that confusion with siblings is unlikely.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the type of data returned (consensus, targets, trend, earnings) but does not mention any caveats like data freshness, latency, or whether the results are read-only (though 'get' implies it). The description adds value by specifying the output content, but it doesn't go beyond what the name suggests in terms of behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently lists all key data points. It has no superfluous words and is well-structured for quick parsing. The use of commas and 'with' to link related items creates a clear flow. It earns high marks for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description serves as the sole specification of return values. It comprehensively lists the major components of the analyst view, which is sufficient for an agent to understand what it will get. The only minor gap is the lack of detail on which symbol is used, but that is covered by the parameter name. Overall, the description is nearly complete for a simple one-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not mention the 'symbol' parameter at all. While the parameter name is self-explanatory in a stock tool context, the rubric requires the description to compensate for low schema coverage. The description fails to add any additional meaning about the parameter beyond its name, which is a gap for a single-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides analyst consensus (buy/hold/sell), price targets with upside, recommendation trend, and earnings dates with EPS estimates and surprises. This distinguishes it from siblings like get_stock_quote or get_financials, though it lacks an explicit verb like 'retrieve' or 'get'. The resource is clearly identified through the content list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The description does not mention any specific scenarios, prerequisites, or exclusions. With 22 sibling tools, the absence of usage context forces the agent to infer the tool's role solely from the content, which is insufficient for optimal selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It does add meaningful context by describing the source (NSE), the nature of the announcements, and the returned fields. However, it does not mention ordering, pagination limits, or the meaning of the PDF link.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-organized sentence that front-loads the core purpose and then lists supporting detail (announcement types and output fields). Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description omits parameter semantics and usage guidance, which are essential given no annotations and no output schema. The provided content information is helpful, but the definition is not complete enough for an agent to confidently invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It never mentions the required 'symbol' parameter or the 'limit' parameter, leaving the agent to infer their roles from the parameter names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource ('corporate announcements filed with NSE') and the content included (subject, short text, PDF link). It is understandable and distinct enough from most siblings, though it does not explicitly contrast with related tools like get_corporate_actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus alternatives such as get_corporate_actions or get_analyst_view. The description implies it is for the latest announcements, but no explicit when or when-not conditions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It only states the data content and time scope ('Today's'), but doesn't disclose behavior like pagination, limit handling, rate limits, or any side effects. The description is minimal and adds little beyond the obvious read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the main purpose. It is efficient and easy to read, though it could be slightly more structured with a clear breakdown of included deal types.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has one parameter that is not explained, no output schema, and no annotations. The description provides the data scope but leaves the agent without knowledge of how the limit parameter affects results or any output format expectations. This is inadequate for a tool that should be easily callable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, 'limit', is completely undocumented in the description. Schema description coverage is 0%, so the agent has no hint about what limit controls (e.g., number of results returned). The description adds no value to parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific resource (bulk deals, block deals, short-selling disclosures on NSE) and the information returned (who bought/sold what at what price). It is distinct from siblings like get_market_pulse or get_top_movers by naming a specialized data type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for today's bulk/block deals on NSE, but provides no explicit when-to-use vs alternatives or exclusions. An agent can infer the use case from the resource type, but there is no guidance on when not to use it or how it differs from other market data tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of disclosure. It discloses the return content but does not mention error handling, authentication, rate limits, or explicitly confirm read-only behavior (though 'get' implies it). This is a minor gap for a simple read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the purpose and efficiently lists the returned fields without redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description adequately describes the return content and parameter meaning. It does not cover edge cases like invalid symbols, but that is not critical for a straightforward profile fetch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clarifies that the symbol is an NSE symbol, adding meaningful context beyond the raw 'string' type. It does not provide format examples, but the exchange qualifier is helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides a company overview for an NSE symbol and enumerates specific data points (sector, industry, market-cap bucket, index membership, business summary, employees, website, valuation). This verb+resource statement distinguishes it from price/quote tools and financial statement tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it is used when a company overview is needed, but it does not explicitly state when to use it over alternatives like get_financials or get_key_ratios. No exclusions or alternative routing are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It usefully scopes the data to NSE and distinguishes upcoming versus recent board meetings, but it does not state return format, time windows, pagination, or any limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with no filler; every listed item carries meaning. It could be more structured with an explicit verb, but it is appropriately concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool, the description conveys the main content well and notes the NSE scope. However, it omits any mention of the symbol parameter, and with no output schema it only partially substitutes for return-value documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one required symbol parameter with no description and 0% schema coverage, and the description never mentions the symbol parameter or how it filters the corporate actions. The meaning of 'symbol' is standard, but the description adds no parameter-level semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource concretely: dividends, bonus, splits, rights, buybacks, and board meetings with ex-dates and record dates. It is clearly distinct from generic siblings like get_announcements or get_stock_quote, though it lacks an explicit verb such as 'Retrieves'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives, and there are no exclusions or references to related tools. The description defines the content but leaves the selection conditions to the agent's inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the transparency burden. It discloses the key behavioral scope: latest-day only, cash-market, NSE source, and rupee-crore units. It does not describe the response shape or edge cases such as missing data, but this is a simple zero-parameter 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence packs the key facts: recency, instrument types, market segment, metric, units, and exchange. There is no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description gives enough to know what the tool returns and its scope. It could briefly clarify the response format, but the named fields (buy, sell, net) make the returned data predictable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema confirms this with an empty properties object. The description does not need to explain parameter meanings, so the baseline score of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description precisely identifies the resource: the latest day's FII/FPI and DII cash-market buy, sell, and net flows in ₹ crore from NSE. It is immediately distinguishable from all sibling tools, none of which cover this specific data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is clear: call this tool when the agent needs the most recent FII/FPI and DII cash-market flow figures. It does not name alternatives or exclusions, but no sibling tool offers comparable data, so explicit routing guidance is less necessary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral burden, and it adds meaningful details: currency unit (₹ crore), fiscal year end (31 Mar), and data window lengths for annual and quarterly periods. It does not describe the full return format or the exact meaning of 'all', but as a read-oriented financial data tool it conveys the key behavioral scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loads the core meaning, and uses a readable pipe-separated format for allowed values. Every sentence adds information; there is no filler or repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers parameter choices and data ranges but lacks guidance on when to use this tool versus sibling tools and does not clarify what the output looks like, especially for 'all'. Since there is no output schema and no annotations, a bit more context about expected return structure or exclusions would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for the two optional parameters by listing allowed values and period ranges. It adds meaning beyond the bare schema, especially around annual vs quarterly windows. The required 'symbol' parameter is left to inference, though its meaning is fairly obvious from the tool name and context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource as financial statements and adds the unit (₹ crore), which gives concrete meaning. It enumerates statement types and period options, making the tool's scope specific. However, it does not explicitly differentiate this tool from close siblings like get_key_ratios or get_company_profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful context about available periods (annual last 4-5 fiscal years, quarterly last 5 quarters) and statement types, which implies when it would be used. It does not explicitly state when to choose this tool over alternatives or mention exclusions. Usage guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the data source (NSE official lists) but does not disclose read-only nature, error behavior, return format, or any limitations. This is a significant gap 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core function. It contains no fluff and lists supported inputs compactly, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the purpose and supported inputs adequately. However, it omits return structure, error handling, and any special conditions, which would be valuable for an agent calling it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It provides concrete examples of valid index values (NIFTY 50, BANK, IT, etc.), which helps the agent populate the 'index' parameter. However, the list is non-exhaustive and the description doesn't explain the default behavior beyond the schema's default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns constituent stocks of an NSE index with industry labels, and lists a wide range of supported indices. It distinguishes itself from siblings like get_index_performance, which focus on performance metrics rather than constituents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any exclusions or conditions. The description only states function and supported indices, leaving the agent to infer appropriate usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It is transparent about the output content and the grouping scope, which is helpful, but it does not mention response size, sorting, pagination, or any operational constraints. For a read-only snapshot tool this is acceptable but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact lines with no filler: one line states the output, the other states the filter options. It is front-loaded, scannable, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter and no output schema, the description supplies the essential call semantics: the return metrics, scope, and group filter. The only notable gap is that the group categories are not explained, but this is minor for constructing a valid call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only a bare string parameter with 0% coverage, so the description must compensate. It does enumerate the allowed group values (all, broad, sectoral, thematic, strategy), which lets an agent form a valid call, but it does not define what each group category means.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource ('All NSE indices') and the exact data returned (last value, % changes, PE, PB, dividend yield). This is enough to distinguish it from siblings like get_index_constituents, though it does not explicitly name an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'group: all | broad | sectoral | thematic | strategy' line provides useful filtering context and implies this is the tool for index-level performance snapshots. However, it does not explicitly say when to use it versus related tools such as get_index_constituents or get_market_pulse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates that the tool provides ratio data, which implies a read operation, but it does not disclose output structure, data vintage, coverage limitations, or whether all listed ratio categories are always present. For a tool with no annotation safety signals, this is a meaningful gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, dense sentence that front-loads the full scope of ratio categories without filler. It could be improved by adding a verb and a brief usage hint, but as written it is appropriately compact and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-symbol read-only lookup tool, the category list gives an agent a reasonable idea of what to expect, and the only required parameter is obvious. However, with no annotations, no output schema, and no explanation of the return shape or time period, the description is only minimally adequate for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for its single parameter, symbol, and the tool description does not compensate by explaining symbol format, exchange suffix, or expected value examples. The description adds no meaning beyond the schema field name, so this dimension falls to the lowest score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a clear resource (key ratios) and enumerates the specific categories returned: valuation, profitability, growth, leverage, cash flow, per-share and ownership ratios. It lacks an explicit verb like 'returns' or 'fetches', but the tool name and category list make the purpose understandable. It partially differentiates from siblings by naming ratio-focused content, though not explicitly naming alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus siblings like get_financials, get_shareholding, or get_analyst_view. It merely lists what the tool returns. There are no exclusions, prerequisites, or alternative tool mentions, leaving the agent to infer usage from the name and category list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully states that results are limited to the current year and sorted upcoming-first, but it does not describe output format, update cadence, or explicitly confirm that this is a read-only operation beyond what the tool name suggests.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no filler. It front-loads the most important facts—what the tool returns, the market segment, the time scope, and the sort order—and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, simple list retrieval with no output schema, this description is largely complete: it states the resource, scope, and ordering. The main gap is that the exact return structure/date format is left to inference, but the expected data is self-evident enough for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters to document, so the baseline is 4. The description adds a small amount of context by specifying the scope ('current year') and ordering, which clarifies that no user input is needed for this tool's operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource: NSE equity (capital market) trading holidays, with the scope limited to the current year and a defined ordering (upcoming first). It is distinguishable from sibling market-data tools, though it lacks an explicit action verb like 'retrieves' or 'lists'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No alternatives or when-not-to-use conditions are mentioned, but the description implies usage: when the agent needs NSE trading holiday information. The uniqueness of this zero-parameter tool among siblings makes the intended context reasonably clear, but it does not explicitly route the agent away from other market-data tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of disclosing behavior. The description is content-focused and implies a read-only retrieval through 'snapshot', but it does not explicitly state that it is a safe read, mention any data latency, or describe what 'market status' precisely means. There is no contradiction, but the behavioral disclosure is only adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads its value proposition ('One-call market snapshot') and then lists all components with no filler or redundancy. Every listed item is relevant and informative, making the description both concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description does the essential work of enumerating the return categories, which it does comprehensively. Minor ambiguity remains around 'market status' (open/closed vs. trend) and the exact number or format of sector leaders/laggards, but these are not critical gaps for an agent deciding whether to call this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is fully covered and there is nothing for the description to explain about parameter semantics. The baseline for 0-parameter tools is 4, and the description appropriately focuses on the output rather than inventing parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource (market snapshot) and enumerates its specific contents: market status, indices with % change and PE/PB, India VIX, sector leaders/laggards, and FII/DII cash flows. This clearly distinguishes it from siblings like get_index_performance, get_top_movers, and get_fii_dii, which cover only subsets of this data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening phrase 'One-call market snapshot' gives clear usage context: use this tool when you want a broad overview of multiple market data points in a single request. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough for an agent to choose it over composing multiple separate calls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that data is for today and NSE, but does not explain whether the data is real-time, end-of-day, how 'most active' is computed, or any limits/quirks. This is a short read-only-type query, but behavioral details are minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that wastes no words. It could be more structured by adding parameter guidance, but for an overview it is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and zero parameter descriptions, this description is too thin for reliable invocation. An agent missing the schema and defaults would not know exact parameter values or what response to expect. It is minimally useful but not complete for autonomous use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% parameter description coverageage, so the description must compensate. It partially does: 'by traded value or volume' explains the purpose of the 'by' parameter. However, 'limit' is not described, and the exact accepted values for 'by' are not spelled out. The defaults help but do not fully clarify semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a specific resource: most actively traded stocks today, by traded value or volume, limited to NSE. This is a clear verb+resource pairing, though it doesn't explicitly distinguish itself from sibling tools like get_top_movers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus siblings such as get_top_movers or get_market_pulse. The description implies a use case (most active stocks) but does not state conditions, exclusions, or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It discloses the return format (including expiry format DD-Mon-YYYY and default to nearest expiry), and lists the specific data returned. It implies a read-only operation without stating it, and does not mention error handling or edge cases, but the provided details are sufficient 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, composed of three sentences, and front-loaded with the core purpose. It efficiently lists return items without fluff, and places the expiry format note at the end. Every sentence adds value, making it well-structured and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description enumerates the returned data in detail (spot, expiry list, PCR, max pain, top OI strikes, and a table with specific fields). It covers the expiry parameter and valid symbols, but omits an explanation of 'strikes_around', which is a key parameter. The overall coverage is strong but not exhaustive, warranting a 4.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no descriptions (0% coverage), so the description must compensate. It explains the expiry parameter's format and default, and enumerates valid symbols (NIFTY, BANKNIFTY, FINNIFTY, MIDCPNIFTY) for the symbol parameter. However, it does not explain the 'strikes_around' parameter, leaving its purpose and effect ambiguous. Thus, only partial parameter semantics are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: retrieving an option chain from NSE for indices or F&O stocks. It specifies the resource (NSE option chain) and enumerates the returned data (spot, expiry list, PCR, max pain, top OI strikes, and a compact table with fields). It is immediately distinguishable from sibling tools, none of which relate to options.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use it (for NSE indices or F&O stocks) and specifies the expiry format and default behavior. However, it does not explicitly contrast it with alternative tools or state conditions when not to use it. The absence of explicit alternatives is minor given the uniqueness of the tool, but it prevents a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full disclosure burden and mostly meets it. It reveals the return scope (return calculations, SMA20/50/200, RSI14, max drawdown, annualized volatility) and hard constraints (candles ≤ 400, intraday max 60 days). It stops short of describing response shape or error conditions, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A dense, single-paragraph description that front-loads the core purpose before diving into parameter details. Parameter names are consistently backticked and constraints are stated economically. Every sentence earns its place, though the indicator list is long by necessity rather than brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must convey the response, and it covers the data categories (OHLCV, returns, indicators). However, it never states the response shape, ordering, units, or how bars are structured, which an agent would need given the absent output schema. Constraints and data content are solid, but response format is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does for three of four parameters: it lists valid period values, valid interval values with the intraday distinction, and explains the meaning of candles with a cap. The required symbol parameter is left undocumented, but its meaning is self-evident, and the coverage gap for the tricky parameters is well addressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific resource and action ('Historical OHLCV plus computed stats'), making the tool's function unmistakable. The enumeration of technical indicators (SMA, RSI, drawdown) further clarifies what it returns. It does not explicitly name or contrast siblings like get_stock_quote, so it lands at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this tool versus the many siblings (get_stock_quote, get_top_movers, compare_stocks, etc.). No exclusions, prerequisites, or scenario-based instructions appear anywhere. The content is purely parameter-value documentation, so the agent must infer the fitting use case on its own.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It adds useful source context ('NSE filings (quarterly)', 'Yahoo's insider/institution split') and an interpretive note about promoter stake and pledge, but it omits output shape, rate limits, or caveats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no wasted words. The core resource is front-loaded, and the second sentence adds a meaningful interpretive insight about rising promoter stake and pledge rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

As a simple getter with no output schema, the description is adequate for recognizing the tool's general return content, but it leaves key invocation details unexplained, such as how 'quarters' maps to the parameter and what the exact output fields are.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. The phrase 'quarterly' hints that 'quarters' may relate to the time span, but it does not clarify the symbol format, what the integer represents, or that the default is 8. This is minimal compensation for the two parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's purpose: retrieving a promoter vs. public shareholding trend from NSE filings and Yahoo's insider/institution split. It uses a specific verb and resource, making the tool's function evident, though it does not explicitly contrast it with sibling tools like get_fii_dii or get_company_profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use this tool versus alternatives. The description implies the tool is for shareholding analysis, but it does not state conditions, prerequisites, or exclusions, leaving the agent to infer usage context on its own.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It only lists the returned data fields and does not disclose whether the quote is real-time or delayed, whether authentication is required, how invalid symbols are handled, or that this 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence that front-loads the core purpose and follows with a clearly structured list of return fields. Every word earns its place; no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description clearly enumerates the return values, which is the main contextual gap. It remains short of complete because it omits symbol format and error behavior, but for a simple one-parameter read tool it is adequate for selection and basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds 'NSE symbol' context that the schema lacks, and schema coverage is 0%, so some compensation is needed. But it does not specify symbol format, case sensitivity, or examples, leaving the agent to guess how to supply the symbol.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieving the latest quote for an NSE symbol, then enumerates the exact data fields included. This clearly distinguishes it from siblings like get_price_history, get_key_ratios, or get_top_movers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use it: whenever a current NSE quote snapshot is needed. However, it provides no explicit when-not-to-use guidance or alternatives, leaving the agent to infer distinctions from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the disclosure burden. It explains the temporal window ('Today's'), the ranking concept ('top'), and the filtering dimensions. It does not specify the exact ordering basis, return fields, or pagination behavior, but core behavior is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence with the purpose front-loaded and parameter options compactly listed in pipe notation. Every word earns its place with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple all-optional, read-only list tool, and the description covers its core behavior and accepted inputs well. No output schema exists, so an exact return format would be useful, but an agent can infer the result is a ranked list of securities; the gaps are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description meaningfully compensates by defining valid values for index and direction. Two of the three parameters gain semantics beyond the bare schema; limit remains undocumented but has a clear default and intuitive meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific purpose: retrieving today's top gainers or losers. It clearly names the resource type and scope, though it doesn't explicitly differentiate from siblings like get_most_active or screen_stocks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete input context by enumerating supported values for index and direction, which implies when the tool should be used. However, it does not mention alternatives, exclusions, or compare itself to similar tools such as get_most_active.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the local storage path and the action behavior (get returns live quotes), which is helpful. However, it does not specify side effects of add/remove/clear, error handling, or any limitations (e.g., max symbols). The description adds some transparency but not comprehensive behavior details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. It front-loads the primary purpose (personal watchlist stored locally) and then succinctly lists all actions. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is incomplete. It does not specify which parameters are required for each action, the return format for add/remove/clear, or any constraints. For a tool with two parameters and multiple actions, this leaves critical gaps that an agent would need to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the action parameter values but does not clarify which actions require symbols_list (e.g., add and remove presumably need it, clear does not). It also does not elaborate on the format of symbols beyond the schema's array of strings. The description adds minimal value beyond the schema for symbols_list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages a personal watchlist stored locally, with a specific set of actions (get, add, remove, clear). It distinguishes itself from sibling tools by focusing on personal watchlist management rather than market data retrieval, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for personal watchlist operations but does not explicitly state when to use it versus alternatives like search_stocks or get_stock_quote. It lacks exclusions or guidance on context, though the nature of the tool makes its use case fairly obvious. No direct mention of alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does disclose useful behavioral context ('server-side, fast', 'limit ≤ 250') but does not explicitly state that this is a read-only query, how results are returned, or how filters combine. 'Screen' semantically implies non-mutating behavior, but the safety profile is implicit rather than stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but focused: the first sentence states the core behavior and performance trait, then the second sentence enumerates filters and the sort/limit contract. There is no filler, and the most important scoping information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 19 optional parameters, no output schema, and no annotations, the description covers nearly all invocation-critical information: scope, filter domains, units, allowed sector values, sort options, and a hard limit. It does not describe the output shape or the default sort ordering beyond what the schema already provides, but those gaps are minor for selecting and invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 does add real meaning: units ('₹ crore', 'PE (ttm)', '3-month average volume'), the allowed Yahoo sector enum, valid sort_by values, and the result cap. It does not fully map every schema field (for example, 'ascending' and the min/max pairs) but the parameter names in the schema are largely self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Screen'), a clear resource ('all NSE-listed stocks'), and a well-defined operation ('by fundamentals and price action'). Sibling search tools like search_stocks and get_top_movers are clearly different because this is a market-wide fundamental/price screener, not a name search or a pre-computed movers list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use this tool: when the agent needs to filter across the entire NSE-listed universe on fundamentals and price metrics. It does not explicitly name search_stocks as an alternative for name/symbol lookup, so it stops short of a full when-not-to-use statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral transparency burden. It usefully discloses NSE scope and return fields, but it does not explain search behavior such as case sensitivity, partial vs exact matching, handling of multiple matches, or empty result behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loads the core purpose, and uses concrete examples to illustrate valid inputs. The second sentence succinctly lists the expected return fields without unnecessary filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with one required parameter, the description plus schema is largely sufficient to invoke it correctly. The main gap is the lack of explicit limit semantics, but the default value and parameter name make it reasonably inferable. The presence of an output schema also reduces the need to describe return values in detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for both parameters. It adds meaning to 'query' by explaining that it accepts company names or partial symbols, but it says nothing about 'limit' beyond what the parameter name and default value already imply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Find NSE symbols by company name or partial symbol.' It provides concrete examples and enumerates return fields (symbol, name, ISIN, listing date, industry, index membership), making the tool's role clear. However, it does not explicitly distinguish itself from sibling tools like screen_stocks or get_company_profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies a lookup use case: finding NSE symbols by company name or partial symbol. It does not explicitly state when to prefer this tool over alternatives like screen_stocks or get_company_profile, nor does it mention exclusions such as unsupported exchanges or exact-match requirements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.