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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and idempotence are covered. The description adds that each item carries a short summary and a PDF link, which is useful return-format context, but says nothing about the data source's latency, coverage, or failure modes that openWorldHint implies.

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 naming the source and resource first, then the return shape. No filler, though the trailing '...' list is slightly loose rather than a precise enumeration.

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

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

With no output schema, the description usefully covers what comes back (summary plus PDF link), and the fully-described input schema handles parameter semantics. A note on data freshness or whether results are paginated would make it 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 100%, so all four parameters (symbol, days, limit, keyword) are already documented in the schema. The description mentions filing categories, loosely mapping to the keyword filter, but adds no new syntax or meaning beyond the schema's own 'e.g. results, dividend' 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?

States a specific resource (NSE exchange filings) with a concrete parenthetical list of filing types and the return shape (summary + PDF link). An agent can distinguish it from siblings like get_corporate_actions or get_financials, but it never names or contrasts those siblings explicitly.

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 when-to-use guidance, no exclusions, and no pointer to alternatives such as get_corporate_actions for dividends/splits. The scope is inferable from the filings list, but nothing states the condition that should select this tool over a sibling.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered; the description adds real value by disclosing the exact content shape (ex/record dates, upcoming flagged, 12-month paid dividend history, trailing yield). It does not mention auth needs, rate limits, or behavior when a symbol has no actions, but for a read tool this is solid added context.

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

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

A single dense sentence that front-loads the resource and then the covered action types, with no filler. It is slightly run-on with the trailing parenthetical and appended clauses, but every phrase carries content.

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

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

With no output schema, the description must carry the return-value burden, and it does by naming the fields and sections returned (amounts, dates, upcoming flags, dividend history, yield). Combined with a fully documented 2-param schema and read-only annotations, an agent has what it needs, though missing sibling disambiguation keeps it short of a 5.

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 100% and both parameters are documented there (symbol format, limit semantics with default and max). The description adds no parameter-level detail beyond the temporal hints 'upcoming' and 'last 12 months', so the schema does the heavy lifting and baseline 3 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?

States a specific resource (corporate actions for a symbol) and enumerates the action types covered: dividends with amount per share, bonus issues, splits, rights, buybacks. An agent knows exactly what this returns. However, it does not differentiate itself from the closest sibling, get_announcements, which could plausibly cover the same events.

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?

Usage is only implied by the scope of the returned data (corporate actions for a given symbol). There is no explicit when-to-use, no statement of when to prefer this over get_announcements or get_financials, and no prerequisites such as an exchange requirement beyond the schema's 'NSE symbol' note.

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?

Annotations already establish readOnly, idempotent and open-world behavior, so the bar is lower. The description adds genuinely useful operational context the schema lacks: the reporting unit (₹ crore) and the full set of returned metrics, which substitutes for the absent output schema. It says nothing about data coverage, history limits, or behavior when data is unavailable.

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 dense sentence, front-loaded with the primary metrics and ending with the unit convention. Every listed item is meaningful given there is no output schema, though the run-on enumeration is heavy 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?

With no output schema, the description carries the return-value burden and does so by naming the statements, ratios and currency. It omits any caveat about data availability, history depth, or cases of missing/mixed reporting periods.

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 100%, so symbol, period and count are fully documented in the schema itself (including the NSE symbol format and count bounds). The description adds no parameter-level detail beyond the currency unit, so the baseline 3 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 enumerates exactly which financial data is returned (revenue, EBITDA, balance sheet, cash flow, ratios), so an agent knows this is a fundamentals/statements tool, clearly separable from get_quote or get_price_history. It never explicitly names a sibling to contrast with, so it stops short of a 5.

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

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

There is no when-to-use statement, no prerequisites, and no routing advice relative to siblings like get_quote or get_shareholding. The usage is only implied by the content listing — an agent must infer that this is for statement-level fundamentals.

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?

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context about what is returned, but says nothing about truncation from the limit parameter or the cost/shape of the constituent-heavy response, which matters for a tool that can return up to 500 rows.

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 that packs the output contents efficiently with no filler. Slightly dense, but every clause earns its place by describing a distinct data category.

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

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

With no output schema, the description carries the burden of describing the return and does so thoroughly across both index-level and constituent-level fields. The one gap is that 'every constituent's ... approximate weight' understates the limit default of 50, so an agent might assume it always returns the full roster.

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 100%, so index codes, limit bounds and the sort enum are already fully documented in the schema. The description adds no parameter-level detail (e.g., that 'fno' is an accepted alias or how weight-sorting interacts with limit), so baseline 3 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 names a specific resource (an NSE index) and enumerates the exact payload: level, returns, valuation ratios, breadth, and per-constituent price/change/weight. That is enough to separate it from get_quote (single security) and get_market_overview (broad market), though it never explicitly contrasts with those siblings.

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

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

There is no statement of when to reach for this tool versus get_market_overview, get_quote, or search_securities, and no prerequisites or exclusions. Usage must be inferred entirely from the content 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds value beyond them by specifying the exact snapshot contents and that figures are 'today's', which sets freshness expectations — notably important since no output schema exists.

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 that names the payoff ('Today's Indian market in one call') and then lists contents. Every clause earns its place by describing returned data; 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?

With no input params and no output schema, the description carries the return-value burden and does so comprehensively, enumerating every data group an agent would get. Nothing needed to call this correctly is missing.

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 takes zero parameters, so the schema baseline of 4 applies. There is nothing for the description to clarify about inputs beyond the implicit assumption that all output is current-market scoped.

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?

Specific verb+resource ('Today's Indian market in one call') followed by an explicit enumeration of the exact data returned: indices, India VIX, NIFTY 50 P/E and P/B, sector rankings, breadth, gainers/losers, FII/DII flows, USD/INR, holidays. This clearly distinguishes it from narrower siblings like get_quote or get_index.

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 phrase 'in one call' implies this is the aggregate alternative to making many individual sibling calls, which is useful implicit guidance. However, it never states explicitly when to prefer this over get_index/get_quote or any conditions/exclusions, so usage is only inferred.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value by enumerating the returned data because no output schema exists, but it says nothing about data freshness, handling of missing/young funds, or error behavior. No contradiction with annotations.

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 dense sentence with no filler, and the most-sought data (latest NAV, category, fund house) is front-loaded before the return-series detail. The lack of an explicit leading verb costs it the top score but the sentence is otherwise efficient.

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

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

For a single-parameter, read-only lookup whose safety profile is fully covered by annotations, the description adequately covers what comes back even though no output schema exists. Its only substantive gap is the absence of routing guidance versus search_mutual_funds.

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 100% and the single scheme_code parameter is fully documented in the schema (AMFI code from search_mutual_funds, with an example). The description adds no syntax, format or constraint detail beyond that, so the baseline 3 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 enumerates the exact resource contents a scheme lookup returns (NAV, category, fund house, trailing/calendar returns, volatility, drawdowns), which is specific enough for an agent to identify the tool. However, it is phrased as a noun list without an explicit verb and never distinguishes itself from the sibling search_mutual_funds, which is the natural confusion point.

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 when-to-use or when-not-to-use guidance in the description. It does not say this is the detail fetch that follows a search_mutual_funds lookup, nor does it mention any prerequisites. The parameter schema implies provenance of scheme_code, but the description itself offers nothing.

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?

Annotations already declare readOnly, idempotent, and openWorld, so the safety profile is covered. The description adds substantial value by disclosing the exact analytics computed and that live expiries are listed, which is otherwise unavailable since there is no output schema. It still omits data-freshness, rate-limit, or sourcing caveats, so not 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.

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

The definition is a single dense, front-loaded sentence enumerating what is returned, with essentially no filler. The list is long but every clause names a distinct returned metric, so it earns its length.

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

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

With no output schema, the description carries the full burden of describing the return payload and does so thoroughly. For a read-only analytics tool with fully documented parameters and safety annotations, the only missing element is usage routing against siblings.

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

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

Schema description coverage is 100%, so the schema already documents expiry formats, symbol values, rate_pct, and strikes_each_side. The phrase 'around the money' echoes the strikes_each_side/symbol semantics but adds no new meaning beyond the schema. Baseline 3 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 states a specific resource (NSE option chain) and enumerates the analytics returned (PCR, max pain, OI build-ups, ATM IV, straddle implied move/Greeks), so an agent can distinguish it from siblings like price_option or get_quote without opening the schema. It lacks an explicit contrast naming those siblings, so it falls just short of a 5.

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

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

There is no statement of when to use this versus alternatives such as price_option (single-option pricing) or get_quote. Usage is only inferable from the enumerated content ('around the money', listing expiries); no context or exclusions are given.

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?

Annotations already declare read-only, idempotent, and open-world behavior, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait beyond the structured fields: statistics are computed on adjusted prices, which affects interpretation of returns and dividends/splits. It still omits any note on data source latency, rate limits, or 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.

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

Two tight sentences with no filler; the returned-data inventory leads and the adjusted-price caveat is placed last. Slightly list-heavy, but every item conveys what the tool returns.

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

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

With no output schema, the description correctly takes on the burden of specifying the return contents, and it does so thoroughly. Combined with the full parameter documentation in the schema and read-only annotations, an agent has what it needs, though nothing is said about result size limits or missing-data behavior.

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

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

Schema description coverage is 100%, with period, symbol, max_bars, and bar_interval all documented including enums and defaults, so the schema does the heavy lifting. The description adds no parameter-level syntax or interaction detail (e.g., how bar_interval 'auto' interacts with max_bars), which is the expected baseline-3 outcome when coverage is complete.

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 a specific resource (historical OHLCV bars) and enumerates the derived metrics returned (total return, CAGR, volatility, drawdown, moving averages, RSI, dividends/splits), so the agent knows exactly what this tool produces. It does not explicitly contrast with siblings like get_quote or get_index, but the historical/statistical scope makes the distinction inferable.

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 statement of when to use this tool versus alternatives such as get_quote (current price) or get_index, nor any prerequisites, period-selection advice, or exclusions. Usage is only implied by the listed output content.

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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the bar is lower. The description then adds concrete output-shape behavior for two input classes (stock fields vs index fields), which is genuinely useful since no output schema exists. It omits freshness/currency and any rate-limit or coverage notes, keeping it short of 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.

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

Two sentences, no filler, and the stock case is front-loaded ahead of the index case. The dense comma-separated field list is efficient rather than padded, though it reads as an inventory rather than a prioritized summary.

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

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

With no output schema, the description compensates by enumerating returned fields for both modes, and annotations cover the read-only safety profile. What remains missing — data freshness, units/currency, and how it differs from get_index — is minor for a single-parameter lookup but not immaterial.

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 100%, so the symbol parameter is already fully documented, including example formats. The description echoes the stock/index distinction the schema already makes and adds no new syntax or format meaning. Baseline 3 is correct when the schema does the heavy lifting.

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 clear resource (quote) and enumerates exactly what is returned for stocks versus indices, which is more than a restated title. However, it does not distinguish itself from the sibling get_index, which appears to overlap on index quotes, so an agent cannot fully disambiguate from the description alone.

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?

Usage is implied: the tool covers both NSE stocks and index names, and the two-part sentence hints at when each branch applies. But there is no explicit guidance on preferring this over get_index, get_price_history, or get_market_overview, and no stated exclusions or prerequisites.

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?

Annotations already declare readOnly, idempotent, and openWorld behavior, so safety is covered. The description adds meaningful context beyond them: the data source is NSE filings, the cadence is quarterly, and the response includes computed QoQ and YoY promoter stake change. It says nothing about failure modes for invalid symbols or history availability limits.

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

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

A single dense sentence with no filler and the resource named up front. The embedded clause about QoQ/YoY change is informative rather than redundant, though the sentence is long enough that it could be split for faster scanning.

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

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

With no output schema, the description carries the burden of describing returns, and it does so reasonably: promoter/public split per quarter plus QoQ and YoY change. For a simple two-parameter read tool with safety annotations, this is nearly sufficient, with only error behavior and history availability left unspecified.

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 100%, so both parameters (symbol, quarters) are already documented in the schema, including the default of 8 and max of 20. The description's 'by quarter' phrasing aligns with the quarters parameter but adds no format or constraint detail beyond the schema.

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

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

States a specific resource (promoter and public shareholding), its granularity (by quarter), and its source (NSE filings), including derived QoQ/YoY promoter stake change. This clearly separates it from siblings like get_financials or get_quote, though it never names those alternatives explicitly.

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 when-to-use guidance, no statement of preconditions, and no routing to related tools. An agent must infer the usage context entirely from the data content.

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?

Annotations already declare readOnly, idempotent, closed-world, and 'Works offline' corroborates openWorldHint=false. The description adds genuine behavioral value the annotations lack: it discloses the output contents (which Greeks, theta normalized per day) and that the tool also performs IV back-solving, which is a distinct execution path.

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?

Two sentences, zero filler, and the primary capability plus its output list is front-loaded ahead of the alternative IV-solving mode. Every clause carries information.

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

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

With no output schema, the description correctly enumerates the return values and notes the theta-per-day convention. It does not cover edge behavior — e.g. what happens when neither volatility_pct nor market_price is supplied — which would be useful for an agent deciding which optional inputs to pass.

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 100%, so the schema already documents spot, strike, rate_pct, option_type, market_price, days_to_expiry, volatility_pct and dividend_yield_pct. The description only re-emphasizes the market_price/IV relationship the schema already states, adding little beyond the baseline.

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 ('Price') and resource ('a European option'), then enumerates exactly what is returned (delta, gamma, theta per day, vega, rho, probability ITM). 'Works offline' cleanly separates this pure calculator from every sibling, all of which fetch market data (get_option_chain, get_quote, etc.).

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

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

The 'or give market_price to back out implied volatility' clause clearly defines the second invocation mode, and 'Works offline' implies this is the tool to use when you need computed values rather than a data lookup. It stops short of naming a sibling (e.g. get_option_chain) as the alternative for live quotes, so there is no explicit when-not guidance.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the useful workflow fact that returned AMFI codes feed get_mutual_fund, but says nothing about result ordering, pagination or how the limit/plan/option filters affect matching.

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

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

A single front-loaded sentence with zero filler; the workflow hint is appended compactly rather than buried.

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 4-parameter read-only search with a fully documented schema and no output schema, the description covers purpose and downstream use adequately. The only gap is that it does not hint at what a result contains (scheme name, code, plan/option), which an agent might want.

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 100% and enums for plan and option are self-documenting, so the schema carries the parameter burden. The description adds no query syntax or filtering semantics beyond what the schema already states, making the baseline 3 appropriate.

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

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

States a specific verb (Find) and resource (Indian mutual fund schemes and their AMFI scheme codes), and differentiates from the sibling get_mutual_fund by framing itself as the lookup step that feeds that tool. An agent can distinguish it from search_securities without opening either schema.

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 parenthetical 'needed for get_mutual_fund' gives clear downstream context for when to reach for this tool, effectively positioning it as a prerequisite step. It stops short of explicit when-not guidance or naming an alternative search path.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds no behavioral detail beyond them: no mention of pagination, result caps, or partial-match semantics, which for a search tool is a real but modest 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?

Two sentences, zero padding, with the purpose stated first and the usage condition immediately after. Nothing is wasted.

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 two-parameter lookup with full schema coverage and no output schema, the description covers purpose and trigger adequately. It leaves the returned shape (symbol list with names/exchanges) unstated, but that is a minor omission given the tool's simplicity.

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

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

Schema description coverage is 100% and both parameters (query, limit) are documented with examples and bounds, so the baseline is 3. The description adds no syntax or matching guidance beyond what the schema already states.

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 (find) and resource (NSE symbols for company, ETF or index) with the lookup key (by name). The NSE-securities scope implicitly separates it from the sibling search_mutual_funds, though no sibling is named outright.

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?

"Use this whenever the exact symbol is unknown" gives a clear triggering condition that routes the agent here before symbol-based tools like get_quote. No explicit exclusions or named alternatives, so it stops short of a 5.

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