MyFinancial Market Data MCP

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

Discloses several key behaviors beyond the annotations: duplicate stocks are merged by weighted-average price, exchange suffixes must be stripped before calling, and parsed/inferred holdings require confirmation. Since annotations are all false and provide no safety or side-effect hints, this description carries the transparency burden and does so well. 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?

The description is dense but front-loaded with the main action and merge behavior, followed by example, preprocessing rules, and confirmation workflow. Every section addresses a real edge case, though the long suffix list and ALL-CAPS 'STRIP' make it slightly less scannable than it could be; bullets would improve readability.

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 mutation tool with one parameter, no output schema, and minimal annotations, the description covers the main scenarios: single add, bulk add, pasted broker data, symbol normalization, ambiguous-field handling, and fallback to search_stocks and read_me. Minor gaps remain around what the tool returns after success or failure and partial-failure behavior, but the operation is otherwise well specified.

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?

Although the schema already documents holdings, symbol, quantity, and avg_price at 100% coverage, the description adds meaning by mapping a natural-language example to the holdings array and instructing the agent to strip exchange suffixes and pass plain NSE symbols. This clarifies the expected values beyond the schema's generic examples.

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

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

States the operation as 'Add one or more stocks to the user's portfolio', a specific verb and resource. It also clarifies scope by saying it accepts single, bulk, or pasted broker holdings and merges duplicates by weighted-average price, which distinguishes it from the watchlist and update/remove portfolio 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?

Provides explicit conditional guidance: add directly when the user has stated symbol, quantity, and price, but show parsed rows for confirmation when holdings were parsed or inferred. Names search_stocks as the fallback for unresolved symbols and read_me for the full broker-CSV procedure. It does not explicitly contrast with update_portfolio_stock or remove_portfolio_stocks, so it misses 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?

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds the concrete idempotent behavior ('adding a stock that's already followed is a no-op') and clarifies that it operates on the user's personal watchlist, adding context beyond the annotations. There is no contradiction with the 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?

The description is concise and well-structured: a clear opening sentence, three bullet-pointed use cases, and a helpful post-action tip. It is front-loaded with the core purpose and every sentence adds value, avoiding unnecessary verbosity.

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

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

For a simple one-parameter tool with no output schema, the description covers the essential information: purpose, idempotency, use cases, and a follow-up recommendation. It doesn't mention error handling or confirmation responses, but these are not critical for a low-complexity mutation tool, and the provided guidance is sufficient for an agent to invoke it correctly.

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

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

The input schema fully documents the only parameter 'symbols' with a description and example, achieving 100% schema coverage. The description's use cases show sample symbol lists but do not introduce additional semantic meaning about the parameter's format or constraints beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action 'Add one or more stocks to the user's watchlist' with a specific verb and resource, and differentiates from siblings like remove_from_watchlist and get_watchlist by focusing on the addition operation. The three use cases further specify the intent, leaving no ambiguity about what the tool does.

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

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

It provides explicit use cases (single add, bulk add, after user request) that clarify when to invoke the tool. It also includes a post-action suggestion to offer analysis. It doesn't explicitly mention alternatives or exclusions, but the sibling list and title make it clear that this is for watchlist additions, not portfolio operations, so usage context is sufficiently clear.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description reveals important behavior: returns per-event and cumulative factors with ex-dates, includes a reconstruction formula in meta, and critically discloses the unquantified_events field for rights issues and demergers. It also explicitly instructs the agent never to invent factors for those events, which is essential operational guidance.

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 longer than average but every sentence earns its place: function and purpose first, concrete usage triggers second, then the critical unquantified-events caveat, then scope limitations. The important warnings are clearly flagged with 'CRITICAL' and 'NOTE', making the structure 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?

With no output schema, the description carries the burden of explaining the response shape and does so well: per-event factor, cumulative factor, ex-dates, reconstruction formula in meta, and the unquantified_events field. It also covers edge behavior (rights issues/demergers without reliable factors) and scope limits (no dividends/total return), making it sufficient for correct invocation and interpretation.

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 symbol, ticker, and identifier all documented in the schema, so the description does not need to re-explain parameter meanings. It adds no new parameter-specific semantics, but the baseline of 3 applies because the schema already carries the load. Note that all parameters are marked optional in the schema even though their descriptions say 'REQUIRED', but that inconsistency is not introduced by the tool description.

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 action and object: 'Get the split/bonus adjustment-factor timeline for a stock,' and explains the purpose ('so a raw (unadjusted) price series can be reconstructed from the adjusted one'). It distinguishes itself by stating the factors cover only splits and bonuses and that dividends are not included, framing it against related corporate-action or price-history 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 'USE THIS when' clause explicitly lists the triggering scenarios: suspiciously large price moves, requests for raw/unadjusted prices, or questions about adjusting for splits and bonuses. It also gives clear exclusions ('factors cover splits and bonuses only; dividends are not included'), though it does not name sibling tools such as get_corporate_actions or get_price_history as 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?

Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the batch-size constraint and efficiency rationale, but it does not disclose behavior on invalid symbols, partial batch failures, or the exact shape of the returned quotes. That is acceptable but not rich enough to exceed a baseline 3.

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 with no filler: the action and resource are front-loaded, the 20-symbol cap is stated immediately, and the relationship to get_stock_quote is given as a useful closing rationale. 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 low-complexity, one-parameter, read-only batch tool, the description plus rich schema is mostly complete: the agent knows what to pass, the maximum batch size, and when to prefer it. The only gap is the absence of any description of the return format, but the tool is simple enough that this is not a critical omission.

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%: the 'symbols' parameter already documents the array, max 20, example format, and splitting over 20. The tool-level description repeats the max-20 constraint but adds no new parameter semantics, so the baseline 3 for high schema coverage 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 uses a specific verb and resource: 'Get current price quotes for multiple stocks at once.' It is clearly distinct from the single-symbol sibling get_stock_quote by explicitly positioning itself as the batch version, so an agent can confidently select it for multi-symbol requests.

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 clear usage context: use this for multiple stocks, cap requests at 20 symbols, and it is 'more efficient than calling get_stock_quote repeatedly.' It names the relevant alternative but does not explicitly state the exclusion case (e.g., 'for a single quote, use get_stock_quote'), so it falls just short of full when/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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: default response size (~3KB), the fact that optional sections are fetched via parallel API calls, and the critical warning that a null metric means 'not published' and must never be treated as 0. It also discloses that the stock itself is included in the peers table and flagged is_self. This goes beyond the annotations without contradicting them.

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 well-structured with a clear lead sentence, bullet-like sections, and an example. It is longer than average, but every section earns its place: the peers detail is dense but necessary to prevent misinterpretation of null values and is_self. The post-tool suggestions are arguably beyond the core tool description and could be trimmed, but they are clearly separated and actionable. Slight over-length keeps it from a 5.

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 read-only, idempotent tool with no output schema, the description is remarkably complete. It tells the agent what the base response contains, what optional sections exist, how to request them, what the peers table includes, how to interpret nulls, and what to suggest to the user afterward. The only thing missing is a note about error cases or rate limits, but those are not expected in a tool description and the annotations cover safety.

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 all four parameters. The description adds meaning beyond the schema by explaining what the 'include' values actually return (e.g., technicals = RSI, SMA, EMA, MACD, Bollinger Bands, ATR, ADX; ratings = analyst consensus with counts and percentages; peers = comparable-company table with specific columns). It also clarifies that 'symbol' is required even though the schema marks it as not required, and that 'ticker' and 'identifier' are aliases. This is meaningful added value.

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

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

The description opens with a specific verb and resource: 'Get detailed company overview' and enumerates the exact content (sector, about, pros/cons, fundamentals, growth metrics, current quote). It clearly distinguishes itself from siblings like get_live_quote, get_financials, and get_stock_news by stating what is included in the base profile and what is not.

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 explicitly tells the agent when to use the 'include' parameter to add optional sections, and even gives an example ('include ["technicals", "ratings"]'). It also names sibling tools for deeper dives (get_financials, get_forecasts, get_stock_events, shareholding patterns), providing clear routing guidance. The only minor gap is not stating when NOT to use this tool, but the alternatives are named.

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 a safe read-only, idempotent, non-destructive profile, so the description bears less burden. It adds useful context via the alias relationship, single-stock scoping, and covered event types, but says nothing about pagination, output shape, or the fact this is a filtered view of a broader event feed.

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 plus an example, front-loaded with identity then semantics. No filler; the abbreviated type:"corporate_actions" notation is slightly awkward but compact and informative.

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?

Adequate for a simple single-stock list tool backed by strong safety annotations: what it returns and how to call it are clear. The gaps are the absence of an output schema and any description of the returned event structure or how limit behaves beyond its schema default/max.

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 baseline is 3. The example {'symbol':'ITC'} reinforces the symbol format already documented in the schema without adding new meaning, and the embedded type:"corporate_actions" explains the underlying filter but doesn't clarify any parameter behavior 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 verb+resource+scope: retrieve corporate actions (dividends, splits, bonuses, AGMs) for one stock, with a concrete example. Naming get_stock_events as its parent clarifies identity, though it doesn't explicitly differentiate from the overlapping sibling get_adjustment_factors.

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 'Alias for get_stock_events' statement implies get_stock_events is the general tool and this is the corporate-actions-specific view, and the example shows invocation. However, there are no explicit when/when-not conditions and no guidance steering away from overlapping siblings like get_adjustment_factors.

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 destructiveHint=false, covering the safety profile. The description adds semantic context (forward-looking signal on credit/solvency risk, 'over time') but does not disclose additional behavioral traits like pagination, rate limits, or return format. Given annotations handle safety, the description provides modest extra value, warranting a 3.

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 sentences, highly compact, and front-loads the action and key fields. The second sentence provides the purpose and use case without fluff. 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 description lists the output fields (agency, rating, action, outlook) and the temporal aspect ('over time'), giving an agent an idea of what to expect. There is no output schema, so the description partially compensates by indicating the response content. It does not mention pagination or response structure, but for a read-only, alias-parameter tool, the provided information is largely 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 100%: all three parameters (symbol, ticker, identifier) are documented as aliases. The description adds no parameter-specific information, so it relies entirely on the schema. Per calibration, a high-coverage schema yields a baseline of 3, and the description does not exceed that.

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 action ('Get credit-rating actions') with a clear resource (company) and lists the key fields (agency, rating, action, outlook). It is unambiguous about what the tool does. However, it does not explicitly name or differentiate from sibling tools like get_corporate_actions or get_stock_events, though the resource is distinct enough for an agent to infer the difference.

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 explicit use-case context: 'Use for risk assessment and debt-investor research.' This tells an agent when this tool is appropriate. It does not, however, mention when not to use it or name alternatives, but the stated purpose is clear and sufficient for routing.

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 declare readOnlyHint, idempotentHint, and destructiveHint, which already establish safety. The description adds value by specifying the return contents (summary, highlights, risks, guidance, key metrics, links) and the scope (one parsed filing), which is not present in annotations. 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?

The description is two sentences, front-loaded with the core purpose, and includes essential routing information without excess. Every clause contributes to the agent's decision-making.

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

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

Given the absence of an output schema, the description adequately lists return elements. It explains both parameter selection modes and points to alternatives for text retrieval. The tool's complexity is low (no nested objects, few params), and the description covers what an agent needs to 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 coverage is 100%, so baseline is 3. The description adds meaning by explaining the role of doc_id (from list_company_documents) and doc_type (newest of that type) in selection. It also clarifies that symbol is required, though the schema does not enforce a required array—this is a minor inconsistency but still adds guidance. The description compensates beyond the schema.

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

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

The description clearly states the tool provides an 'investor digest of ONE parsed filing' with summary, highlights, risks, guidance, key metrics, and links. It distinguishes itself from sibling tools like read_document by noting it provides a digest rather than raw text, and from get_earnings_call_summary by focusing on parsed filings broadly. The purpose is 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?

Explicitly states how to select a document: 'Pass doc_id from list_company_documents, or doc_type for the newest of that type.' It also directs users away from this tool for raw text: 'For the text itself use read_document or download links.markdown_url.' This is clear when-to-use versus when-not-to 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 destructiveHint, covering the safety profile. The description adds valuable behavioral context: it states the output is AI-generated and grounded in the company's own filings, implying potential AI limitations and source reliability. This goes beyond what annotations provide.

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-structured sentence that front-loads the core purpose and then details what the output includes. It is concise without being terse, and every clause adds value. It could be slightly shorter but is appropriately sized.

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

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

Given the tool has a simple purpose, 100% schema coverage, and no output schema, the description is sufficiently complete. It explains what the tool returns and its intended use case. A minor gap is that the symbol parameter is marked 'REQUIRED' in its schema description but the schema does not enforce it, which could cause ambiguity, but the description clearly flags it.

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 parameters (symbol, limit, ticker, identifier) are documented in the schema. The description does not add any extra meaning about parameter usage, formats, or relationships beyond the schema. It simply mentions 'recent earnings' without elaborating on how limit affects results. This meets the baseline of 3 but does not exceed it.

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

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

The description clearly states the tool retrieves AI-generated investor digests of earnings call transcripts and presentations, specifying the exact resource (earnings call summaries) and verb (get). It distinguishes itself from sibling tools like get_document_summary by focusing specifically on earnings-related content, and mentions the output structure (structured summary, highlights, risks, guidance, metrics).

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 a clear usage context: 'Use for qualitative fundamental research beyond the numbers.' This implies it complements quantitative tools like get_financials or get_screener_ratios, but it does not explicitly name alternatives or state when not to use it. The guidance is helpful but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral context beyond that: it details the scope of data (30-day cash flows, F&O positioning, aggregates, streaks) and the optional chart interval behavior. No contradictions exist.

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 well-structured with a front-loaded opening line and a concise bullet list of data offerings. Every bullet adds information, though the final promotional sentence ('Essential for understanding...') is arguably unnecessary. Overall, 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 burden of explaining what the tool returns, and it does so by listing key data categories (cash flows, F&O positioning, aggregates, streaks). It does not specify exact return structure or units for all fields, but for a read-only data tool with a single optional parameter, this is reasonably 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% for the single optional chart_interval parameter, and the schema already explains it clearly. The description's mention of 'cumulative flow chart data with interval param' slightly reinforces the parameter's purpose but adds no new meaning beyond the schema, justifying a baseline 3.

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 verb+resource ('Get detailed FII/DII institutional flow data') and enumerates the exact data categories returned. This is clear and specific, but it does not distinguish itself from the sibling tool 'get_fii_dii_flows', which likely serves a similar purpose, so it misses the differentiation that would merit 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?

The description implies usage context with 'Essential for understanding institutional money flow in Indian markets,' which tells an agent when it is valuable. However, it provides no explicit guidance on when to use this tool versus alternatives like get_fii_dii_flows, and no exclusions or prerequisites are stated.

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, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds no new behavioral traits beyond listing the types of data returned; it does not mention return format, pagination, or any side effects. With annotations present, the added value is modest but not contradictory.

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 brief and efficient, with the alias declaration front-loaded and data types summarized concisely. However, it repeats the alias information already present in the title, creating minor redundancy. It is appropriately sized with no filler, so it earns a 4.

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 what data is returned. It lists several specific data categories (daily cash market flows, F&O positioning, weekly/monthly/yearly aggregates, buy/sell streaks), giving a solid picture of the content. The optional chart_interval parameter is documented in the schema, and the tool is simple enough that the description largely suffices, though it could mention how the parameter affects output.

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

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

The single parameter chart_interval is fully documented in the schema with an enum and description ('Include cumulative flow chart data for this interval'). The tool description does not mention the parameter at all, so it adds no additional semantic meaning. Since schema coverage is 100%, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: retrieving detailed FII/DII institutional flow data, listing specific data types (daily cash market flows, F&O positioning, aggregates, buy/sell streaks). It distinguishes from general market data tools by focusing on FII/DII flows, but it is explicitly an alias for get_fii_dii_detail, which is a sibling, so it doesn't differentiate from that particular sibling.

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 only states it is an alias for get_fii_dii_detail, providing no guidance on when to use this tool versus alternatives. It doesn't mention any conditions, exclusions, or context for when FII/DII data is needed. The alias statement implies interchangeability but does not explicitly advise when to choose this over 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?

Annotations declare readOnlyHint and idempotentHint, but the description adds critical behavioral detail: the default trimming to 5 periods when section is omitted, the structure of each section (periods, data, pct_changes, row_order, availability), and the meaning of available_from (point-in-time declaration date) plus the caveat about restatements. This goes well beyond the annotations and is essential for correct backtesting usage.

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 paragraph with front-loaded purpose and no fluff. Every sentence contributes: purpose, section definitions, default behavior, period control, data structure, availability semantics, caveat, and usage constraint. It is long but proportionate to the tool's complexity, and each clause 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 six parameters, no output schema, and rich behavioral nuances, the description covers all essential operational details: sections, period defaults and limits (max 40), aliases, one-symbol-per-call rule, and the full response structure including the availability array and its backtest relevance. It also flags unsupported asset types. Nothing an agent needs to call it 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?

Schema coverage is 100% with per-parameter descriptions, but the description enriches semantics further: it explains that omitting section yields latest 5 periods per section, while naming a section yields all periods (unless periods is given), defines the aliases (ticker for symbol, quarters for periods), and clarifies that quarterly is the only quarterly P&L while the other four are annual. The example (symbol TCS, section quarterly, periods 12) demonstrates correct usage.

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 the exact function: 'Get financial statements for one company' and enumerates the sections (quarterly, profit_loss, balance_sheet, cash_flow, ratios). It distinguishes from get_batch_quotes (prices only) and explicitly notes that ETFs/index funds/bonds have no financial statements, so the agent knows precisely what this tool is for and what it is not.

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?

Provides explicit when-to-use guidance: one symbol per call, and for multiple companies call per symbol, referencing get_batch_quotes as the price-only alternative. It also states that ETFs/index funds/bonds are unsupported, and explains how to control period coverage (omit section for latest 5, use periods to widen), with a concrete example (TCS quarterly with 12 periods).

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by stating that data is available by quarterly/annual periods and includes an actuals-versus-estimates comparison, though it does not describe output formatting.

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, roughly 30 words, with the resource and metrics front-loaded in the first sentence and the use case in the second. There is no filler or repetition of structured information.

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

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

Given the tool's low complexity (read-only, 3 alias parameters, no output schema), the description covers what is returned (metrics, periods, comparison) and why it matters. The schema handles parameter aliases and annotations handle safety, leaving only a minor gap around the ambiguous symbol requirement.

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 already documents all three parameters (symbol, ticker, identifier) with full descriptions and 100% coverage, including the alias relationship, so the description does not need to add parameter-level detail. The 'REQUIRED' marker in the symbol description versus the required-parameter count of 0 is a schema inconsistency, but the description contributes nothing 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?

Description opens with the specific verb 'Get' and the resource 'analyst forecasts', then lists the exact metrics covered (EPS, revenue, EBITDA, net income, ROA, ROE, price). The 'actuals vs estimates comparison' distinguishes this from actuals-only siblings like get_financials, so an agent can identify the correct tool.

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 last sentence gives a concrete use case: 'useful for understanding market expectations and earnings surprises.' This tells an agent when to prefer the tool, but it does not explicitly name alternatives or state when not to use it, so it is clear context rather than full routing 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 read-only and idempotent behavior. The description adds value by disclosing output characteristics: the fields returned and the three sorting orders. It also implies the data is periodic (fortnightly, 1-year). This goes beyond the annotations and provides useful behavioral context without contradiction.

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

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

The description is concise: two sentences that front-load the primary action ('Get FPI sector-wise investment data') immediately. Every clause adds information about outputs or sorting. No fluff or repetition. It is ideal in length and structure for an agent to parse.

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

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

For a simple read-only tool with no parameters and no output schema, the description covers the essential aspects: what data is returned and how it is sorted. It does not mention data currency or frequency windows (e.g., as-of dates), but given the field names, these are implied. The description is sufficient for an agent to call the tool without further clarification.

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, so schema description coverage is effectively 100%. The description needs to explain no parameters, and it correctly omits any parameter details. The baseline for 0 parameters is 4, and the description does not add anything unnecessary.

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

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

The description clearly states the tool retrieves FPI sector-wise investment data, lists specific fields returned (AUM share, fortnight change, 1-year cumulative flow, sparkline), and explains the sorting orders. This is specific and distinct from sibling tools like get_fii_dii_flows which cover daily flows, not sector breakdowns.

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 a clear use case: 'useful for understanding which sectors foreign investors are buying/selling.' This implies when to use the tool, though it does not explicitly mention alternatives or exclusions. The context is sufficient for an agent to understand the appropriate scenario, but explicit routing to siblings would strengthen it.

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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the tool is the reverse of resolve_identifier_asof, it returns coverage bounds in the response, and it returns 'out_of_coverage' rather than 'no identifiers' outside those bounds. It does not describe the exact response shape, but with no output schema and annotations covering safety, the added context is strong.

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 every sentence earns its place: it defines the reverse relationship, gives a concrete use case, clarifies the input source, and preempts a common misinterpretation. It is front-loaded with the most important fact (reverse of resolve_identifier_asof) and uses clear formatting with backticks for identifiers.

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 read-only, idempotent lookup tool with two well-documented parameters, the description covers the essential context: what it returns, how to get the input, when to use it, and how to interpret edge cases. The lack of an output schema is mitigated by the description's explanation of the response's coverage bounds. Nothing critical is missing for an agent to call 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 100%, so the schema already documents both parameters. The description adds meaning by explaining that stock_id comes from other tools' meta.stock_id and that the tool does not accept a symbol, which is critical disambiguation. It also notes the date defaults to today (IST), which is in the schema but reinforced. This goes beyond the baseline 3.

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 ('return'), a resource ('symbol and ISIN'), and a clear scope ('given a stock_id and a date'). It explicitly names the sibling it is the reverse of (resolve_identifier_asof), which distinguishes it from the many other get_* tools. The example use case (labeling a 2019 backtest position) makes the purpose concrete.

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

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

The description explicitly says when to use this tool ('to label historical output correctly', 'explaining a rename') and what it does not accept ('does not accept a symbol'). It also clarifies the coverage-bound behavior ('outside them the answer is out_of_coverage, not no identifiers'), which prevents a common misinterpretation. This is strong guidance beyond the schema.

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 mark this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: it returns OHLC plus valuation metrics, is official NSE index data, covers ~140 indices, and explicitly states that intraday is not served and that bars are daily up to 1y and weekly for 2y/max.

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 front-loaded with the core action and data content, then gives usage examples, sibling differentiation, and the multi-index alternative. Every sentence adds useful information; there is no filler or tautology.

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 read-only tool, this is complete: annotations cover the safety profile, schema covers parameter semantics, and the description covers output composition, supported index categories, return-bar cadence, and intraday exclusion. No output schema exists, but the description sufficiently defines what the caller will receive.

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 the baseline is 3. The description adds meaning by clarifying that exactly one index is addressed at a time, providing real index-name examples, and noting the broader universe of '~140 more'. This enriches the parameter understanding even though the schema already documents interval and index_name.

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

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

The description uses a specific verb and resource: 'Get the historical LEVEL series (OHLC + PE/PB/dividend yield) for a single NSE INDEX'. It lists concrete examples, names the counterpart tool get_price_history, and contrasts with get_index_performance, so an agent can distinguish it from its siblings immediately.

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 provides explicit when-to-use examples such as 'what did Nifty IT close at on <date>' and 'India VIX over the last month'. It also states exclusions: individual stocks should use get_price_history, and multiple-index comparison should use get_index_performance.

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 only declare readOnly/idempotent/non-destructive, which the description matches — no contradiction. The description adds substantial behavioral context beyond annotations: the four-state answer semantics where 'uncertain' and 'out_of_coverage' must not be collapsed into 'absent', the requirement to report uncertainty honestly, and the disclosure that answers are only trustworthy up to meta.coverage.answerable_through with a freshness lag. This is exactly the kind of behavioral nuance structured fields cannot express.

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 long but densely informative, front-loading the core question and the four-state contract before usage guidance and meta-field caveats. Every block earns its place for a tool this behaviorally complex; however, there is mild redundancy — 'never a bare yes/no' restates what the four-state list already implies, and the 'REPORT UNCERTAINTY HONESTLY' paragraph partially repeats the 'do not collapse' rule from the state definitions.

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 fully compensates by explaining the answer domain (four states), the return metadata (meta.coverage and meta.freshness.lag_days), and the trust boundary (answerable_through). For a complex point-in-time query tool with an open-world-ish answer space, this covers everything an agent needs to call it correctly and interpret results safely. The only nuance not stated — that index and symbol are semantically required despite a formal required count of 0 — is already in the schema descriptions.

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 all five parameters (date format/default, required index and symbol, ticker and identifier aliases), establishing the baseline of 3. The description does not add parameter-specific semantics beyond the schema — the as-of concept is conveyed by the tool name and title rather than per-parameter detail. The description is not required to compensate, so a 3 is appropriate.

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

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

Opens with a specific verb+resource question ('Was a stock a constituent of an index on a specific historical date?') and immediately differentiates scope by defining the four-state answer domain. The tool is clearly distinguished from siblings like get_index_history (index values, not membership) and resolve_identifier_asof / get_identifiers_asof (identifier resolution, not membership).

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?

Explicitly states when to use it ('USE THIS for any "was X in the Nifty 50/500 on <date>" question, and for point-in-time universe construction or survivorship-bias-aware backtests') and gives a clear when-not with the exact failure mode it prevents ('Do NOT infer historical membership from today's constituent list — that is exactly the survivorship bias this tool exists to avoid'). An agent needs no inference to decide routing.

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 destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond that: the in-progress period is excluded ('Only COMPLETED periods are counted'), the data source is specified ('official NSE index closing levels'), and the return shape is disclosed (per-period plus cumulative, sorted). These are semantic nuances that materially affect result interpretation.

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?

Five sentences with the core purpose front-loaded in the first sentence, followed by output format, coverage scope, usage guidance, and the behavioral caveat in logical order. The sector enumeration is long but defensible as it documents the coverage claim (~140 indices). Every sentence earns its place, though the list could be tightened.

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 read-only ranking tool with six optional parameters and no output schema, the description covers everything an agent needs: what it computes, the output structure (compensating for the missing output schema), coverage scope, when to use it, and the completed-periods caveat. No critical operational gap remains.

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 schema already explains all six parameters clearly, including the meaning of 'completed periods', the gainers/losers ordering, and the 'sectoral for sector rankings' guidance on category. The description reinforces these concepts but does not add meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Rank NSE indices by RETURN over recent completed weeks or months') with a defined output ('per-period % plus cumulative %, sorted best-to-worst'). The scope is unambiguous and the example queries ('rank sectoral indices by 3-week return', 'which sector performed best last month') make it easy for an agent to map user intents to this tool, distinguishing it from get_index_history (raw price history) and constituent-based estimation.

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?

Provides explicit positive guidance ('USE THIS for...') with concrete natural-language query examples, plus an explicit exclusion ('do NOT compute a sector return from its constituents, which is only an approximation'). While no sibling tool is named by name, the directive is specific and actionable, covering both when-to-use and when-not-to-use with clear 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context: it returns latest value, daily change, and recent history, and explains the interpretation of rising/falling VIX. It doesn't contradict annotations and adds meaningful transparency.

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

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

The description is two concise sentences, front-loading the core purpose and then adding interpretation and use case. Every sentence earns its place with no waste.

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 read-only tool, the description covers the essential information: what it returns and how to interpret it. It doesn't specify units, frequency, or data source, but these are minor and not critical for calling the tool. The description is adequate for an agent to use it correctly.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, 0 parameters baselines at 4. The description doesn't need to elaborate on parameters; it adds value by describing the output semantics, which is appropriate.

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

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

The description opens with 'Get the India VIX' – a specific verb and resource. It explains what the VIX is (expected near-term volatility, 'fear gauge') and what it returns (latest value, daily change, recent history). It clearly distinguishes this tool from the many siblings by focusing on the VIX index itself, not generic index history or performance.

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

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

The description explicitly states when to use it: 'Use for market-timing and risk context.' This provides clear usage context. It doesn't mention when not to use it or alternatives, but given its highly specific scope, the guidance is sufficient.

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 destructiveHint=false, so the safety profile is clear. The description adds the single-symbol scope and alias relationship, but discloses nothing about return format, delays, or error behavior. With annotations lowering the bar, a 3 is appropriate.

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 short sentences plus a concrete example contain no filler. The alias relationship is front-loaded, 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 simple read-only alias with full schema coverage and rich annotations, the description is sufficient for selection and invocation. It does not mention return format, and there is no output schema, but the tool's trivial nature and clear single-symbol scope minimize the gap.

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 symbol, ticker, and identifier. The description adds only an example ('{"symbol":"RELIANCE"}') without explaining semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description opens with 'Alias for get_stock_quote', which names the canonical sibling and positions this tool as a direct alias. 'Latest price for one symbol' states the resource and scope clearly, distinguishing it from multi-symbol tools like get_batch_quotes.

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 explicitly says 'one symbol', so an agent knows this is for single-symbol latest-price lookups. It names get_stock_quote as the canonical version, but does not explicitly state when not to use it or mention alternatives such as get_batch_quotes for multiple symbols.

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 this tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: feeds are market-wide, scoped to 'today', and each feed is described with its focus and interpretation, e.g., 'Rising = bullish leverage, falling = deleveraging.' It does not go into pagination or response shape, but annotations cover the safety profile.

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 long but every sentence serves a purpose: each bullet maps one enum value to a concrete and useful explanation. The opening sentence and routing sentence keep the structure tight, and there is no redundant or filler 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?

For a single-enum-parameter tool with no output schema, the description is nearly self-sufficient: it lists all possible values, explains what each returns, and points to sibling tools for adjacent use cases. The only small ambiguity is whether dataset is truly required, but the param-level 'REQUIRED' and 'Pass dataset to choose' make the intent clear.

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%, but the description adds substantial meaning beyond the simple enum list. Each dataset value is expanded with the fields it returns (e.g., deals includes 'deal type, symbol, client name, buy/sell, qty, price, value') and interpretive guidance, which is exactly what an agent needs to select the correct enum.

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

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

The description uses a specific verb and resource—'Get one of today's market-wide data feeds'—and enumerates the seven feed choices with concrete content for each. It also distinguishes itself from siblings by explicitly naming market_valuations, market_heatmap, and get_stock_deals as alternatives for related but different 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 final sentence gives explicit routing guidance: use market_valuations for index PE/PB history, market_heatmap for index heatmaps, and get_stock_deals for a single stock's deal history. This tells the agent exactly when not to use this tool and which alternative to pick.

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 mark the operation readOnly, idempotent, and non-destructive, covering the safety profile. The description adds useful behavioral context beyond that: it is 'latest' and 'market-wide', and because there is no output schema it discloses the response shape (sentiment tag, category, source URL, symbols), which helps set expectations.

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 text is front-loaded with the core purpose, then a purposeful category list, then a one-line routing rule. It is slightly long because of the category enumeration, but every block earns its place and there is no filler.

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

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

With no output schema and a complex sibling set, the description covers the returned fields, valid categories, optional filters, and the main alternative tool. Nothing an agent needs in order to invoke it 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 schema already describes all 3 optional parameters with 100% coverage, so this dimension starts at the baseline. The description adds meaning by enumerating the full category vocabulary (companies, global, markets, ipo, etc.) and specifying sentiment values in the first sentence, going beyond the schema's examples.

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

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

The description states a concrete action ('Get latest market-wide news') and a clear resource scope ('across all categories'), then lists the returned article fields. It explicitly contrasts with stock-specific news, so an agent can tell it apart from sibling tools like get_stock_events or get_stock_news without opening their schemas.

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 an explicit when-to-use instruction ('Use this for broad market news') and a named alternative for the excluded case ('For stock-specific news, use get_stock_events with type 'news' instead'), which is the exact routing guidance an agent needs.

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 destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations by clarifying the tool returns a consolidated snapshot of multiple data categories (flows, valuations, volatility) in one call, and frames it as a 'quick' overview. It doesn't detail return format or units beyond 'crores', but for a zero-parameter read-only tool, the description adds sufficient behavioral context.

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

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

The description is two sentences: the first front-loads the core purpose and contents, the second routes to alternatives. Every clause earns its place; there is no fluff or repetition of schema/annotation data. The structure is ideal for quick agent parsing.

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, read-only, idempotent tool with no output schema, the description is nearly complete. It tells the agent what data it will get and when to use it. The only minor gap is not describing the exact response shape or units for valuations/VIX, but since there is no output schema and the tool is simple, the description covers the essential context.

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

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

The tool has zero parameters, so the schema is trivially complete (100% coverage). The description adds value by explaining what the tool returns, which is the only semantic content an agent needs. Baseline for 0 params is 4, and the description earns it by clearly enumerating the output categories.

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 ('Get') and resource ('today's market snapshot') and enumerates the exact contents: FII/DII net flows, Nifty 50 valuations, and India VIX. It also explicitly distinguishes itself from sibling tools by naming get_market_data and get_trending_stocks as alternatives for different use cases. This is a clear, specific purpose that an agent can act on without ambiguity.

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 explicitly says this is the 'quick daily-overview tool' and provides when-to-use guidance by naming alternatives: use get_market_data with dataset: 'signals' for technical signals, and get_trending_stocks for gainers/losers/most-active. This is direct routing guidance that tells the agent exactly when to pick this tool over siblings.

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 indicate readOnly, non-destructive, and idempotent, so the description doesn't need to repeat those. It adds valuable behavioral context: it discloses the honesty limits of the response's 'classification_limits' field, explaining that 'no_print' does not distinguish illiquid no-trade from suspension from missing data, and that 'pre_listing' is only asserted when a listing date is known. This goes beyond just the safety profile and provides critical interpretation guidance. It doesn't contradict annotations, but could have added more about rate limits or output structure, hence a 4 instead of 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 description is fairly long but every sentence earns its place: it defines the purpose, gives usage guidance, and provides critical interpretation warnings. The front-loaded sentence clearly states the verb, resource, and output categories. The warning about zero returns is important, and the honesty limits are necessary for correct interpretation. The structure is effective—purpose first, then usage, then caveats. It is slightly verbose but not padded, so a 5 is justified given the complexity of the tool.

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

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

Given the tool's complexity (multiple classification reasons, honesty limits) and the absence of an output schema, the description does an excellent job of covering what the agent needs to know to call it correctly and interpret results. It explains the classification values, the meaning of 'no_print', and the limitations of 'pre_listing'. However, it does not explicitly mention that the response will contain a classification for every day in the window, nor does it discuss pagination or response structure details, but those are minor gaps. The description is nearly complete for an agent to use the tool effectively, so a 4 is appropriate.

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 already describes all four parameters with 100% coverage: `days`, `symbol`, `ticker`, and `identifier`. The description does not add new meaning to these parameters; it mentions 'lookback window' but doesn't elaborate on the parameters beyond what's in the schema. Since schema coverage is high, a baseline of 3 is correct. The description's value lies in the conceptual output classification, not in parameter semantics.

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

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

The description clearly states the tool's purpose: for each calendar day in a lookback window, it returns why a price is or is not present, enumerating the specific classification reasons (traded, weekend, holiday, etc.). It includes a concrete resource ('Per-Day Observation Status') and verb ('get'), making it distinct from the many sibling data getters, though it doesn't explicitly name a sibling. The level of specificity—explaining the exact output classifications—makes the tool's 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 gives explicit guidance on when to use it: when a price series has gaps and the user needs to know whether a missing day was a market holiday, suspension, pre-listing, or genuinely missing. It also provides a strong 'when not to use' by warning that a missing price is NOT a zero return and should be treated as not-a-return, not 0%. Though it doesn't name a specific alternative sibling, it effectively tells the agent when this tool is the right choice (before computing returns over gappy series), which is more than sufficient.

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 and idempotentHint=true, but the description adds critical behavioral context: it is an end-of-day snapshot (not streaming), explains percent units, and details null handling (nulls are unpublished, never zero) and specific flags like iv_unsolved, illiquid, and pcr_undefined. This goes far beyond what annotations provide.

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?

Though lengthy, the description is densely packed with essential operational details — purpose, usage, caveats, units, null handling, and presentation rules — all front-loaded and logically ordered. Every sentence earns its place given the tool's complexity; there is no redundancy.

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

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

With no output schema, the description compensates by naming key output fields (snapshot_ts, iv_pct, atm_iv_pct, atm_offset, available_expiries) and explaining their meaning. It also covers edge cases like null flags and instructs proper presentation. An agent has everything needed to call and interpret 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 100% for all 5 parameters, so the description doesn't need to explain them. The description does reference output fields (snapshot_ts, iv_pct, atm_offset) but not input parameters. The baseline of 3 applies because the schema already documents parameters fully; the description adds no extra parameter-level nuance.

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

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

The description clearly states the tool retrieves an INDEX OPTION CHAIN with IV, Greeks, bid/ask, and open interest by strike. It also distinguishes it from siblings by explicitly mentioning that get_option_iv_history covers stocks, making the scope 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 provides explicit when-to-use guidance with example queries ('show me the NIFTY option chain', 'what is the ATM IV', etc.) and explicit when-not-to-use (stock options) with an alternative tool named. This fully routes the agent to the correct tool.

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 destructiveHint=false, and the description still adds substantial context beyond them: IV fields are percents that must never be re-scaled, iv_rank_pct and iv_percentile_pct are distinct measures, 2y+ ranges return weekly bars, a single call caps at 400 bars, and the response self-declares coverage and spot_is_proxy. It even adds a no-trade-recommendation guardrail. 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?

Long but zero-waste: the core payload list and the costliest trap (percent units) are front-loaded before use cases, and every subsequent sentence (weekly rollup, 400-bar cap, coverage/spot_is_proxy, no-trading guardrail) addresses a distinct failure mode. No filler, no repetition of schema 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 and no nested objects, the description carries the full burden of return semantics and meets it: fields enumerated, units specified, sampling and length limits stated, and response flags called out. Parameter and safety dimensions are covered by schema and annotations respectively, leaving no critical gap for a 4-param historical query tool.

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

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

Schema coverage is 100% — the schema already documents the range enum, marks symbol REQUIRED, and explains ticker/identifier aliases — so the baseline is 3. The description adds marginal meaning by bounding the symbol domain ('Covers ~556 underlyings INCLUDING individual stocks') and grounding the unit caveat to the returned fields that any range argument will produce.

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 precise verb and resource ('Get the HISTORICAL option-analytics time series') and enumerates the exact fields returned (ATM IV, IV rank, IV percentile, realised vol, PCR OI/volume, max pain, 25-delta skew). It explicitly differentiates from the closest sibling: 'unlike get_option_chain, which is index-only'. An agent cannot mistake this for any of the 60 sibling 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?

Gives concrete user intents ('is IV high right now', 'IV rank of RELIANCE', 'has volatility been rising') plus a general applicability statement ('any volatility-regime / IV-vs-realised comparison'). It names the alternative (get_option_chain) and the condition that selects it (index-only vs ~556 underlyings including stocks), satisfying the explicit when/alternative bar.

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 destructiveHint=false, so the safety profile is covered. The description adds useful detail that the output is broken down per expiry and includes computed metrics, but it does not disclose behavior beyond that, such as data freshness, symbol coverage, or response shape.

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 sentences with no filler. The core action and metric list are front-loaded, and the use-case guidance is appended efficiently. Every clause contributes either to scope, output content, or intended usage.

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 read-only analytics tool with strong annotations and a fully described parameter schema, the description is largely complete: it names the input, the output metrics, the per-expiry breakdown, and the intended use cases. It loses the final point because it does not address the relationship to overlapping siblings like get_option_chain or get_option_iv_history, which would help an agent make a fully informed selection.

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

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

Schema description coverage is 100%, with each parameter self-explanatory: symbol is the stock symbol, and ticker/identifier are aliases. The tool description adds no per-parameter meaning beyond the schema, which is acceptable at the baseline 3 since the schema already carries the semantic load.

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 verb and resource: "Get derivatives analytics for a stock," then enumerates the exact metrics delivered (ATM IV, IV rank, realized volatility, put-call ratio, max pain, 25-delta skew, open interest). This clearly explains what the tool does, but it never explicitly distinguishes itself from siblings like get_option_chain or get_option_iv_history, so it stops short of full differentiation.

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 final sentence says to use it for "options strategy, volatility analysis, and gauging derivatives-market positioning," which gives concrete context for when this tool is appropriate. However, it does not mention alternatives or exclusion criteria, such as when an agent should prefer get_option_chain for raw chain data instead.

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 destructiveHint=false. The description goes beyond this by disclosing the silent 2000-day cap, the meta.window.truncated flag, and the follow-up cursor behavior. It also notes that unsupported intervals return an explanatory error, giving agents full visibility into edge cases.

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

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

The description is thorough but not bloated. It is front-loaded with the core purpose and format, then addresses key caveats. Each sentence adds value, though it could be slightly more compact by merging the paging detail into one flow. Still, it is well-organized 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?

With no output schema, the description carries the burden of explaining the return format and meta fields. It fully covers the row-per-day format, the importance of `meta.window.truncated`, and the paging mechanism. For a tool with this complexity, nothing critical is missing; an agent can confidently invoke it and interpret results.

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%, yet the description adds significant meaning: it clarifies that `days` controls the window while `interval` controls aggregation, explains the `end_date` pagination cursor, and details how `meta.window` reveals truncation. It turns ambiguous schema from a potential footgun into a clear, safe pattern.

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 (Get) and resource (OHLCV price history), and specifies the row format (date, open, high, low, close, volume, delivery %). It clearly distinguishes this tool from siblings like get_index_history or get_live_quote by focusing on historical price data with aggregation. The purpose is unambiguous and actionable.

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 explicitly recommends this tool for price analysis, trend detection, and technical calculations, and warns against unsupported intervals (intraday/monthly) that return errors. It also gives detailed pagination instructions for multi-year requests, leaving no ambiguity about when and how to use it.

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 destructiveHint=false, so the safety profile is fully covered. The description adds useful return-content context (quarterly pledge percentages plus pledge creation/release events), which goes slightly beyond the annotations, but it does not discuss units, reporting lag, edge cases, or response format. 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?

Three sentences with the core purpose front-loaded in the first sentence, followed by return content and a selection-relevant risk signal. Every sentence earns its place, though the trailing 'governance red flag' note is slightly editorial rather than purely functional.

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 present, the description compensates by stating what data comes back (quarterly pledge percentage and pledge events). The tool is simple with fully documented aliased parameters, so nothing essential for a correct call is missing; minor gaps like date range semantics are acceptable at this complexity.

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

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

Schema description coverage is 100%, so all three parameters (symbol, ticker, identifier) are fully documented as the same lookup field. The baseline of 3 applies since the schema carries the parameter documentation burden; the description adds no parameter-level semantics 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?

The description states a specific verb+resource ('Get the promoter share-pledge history for a stock') and precisely what it returns (pledge percentage over quarters plus creation/release events). It is distinct from siblings like get_stock_ownership and get_shareholding by virtue of the focused pledge content, though it does not explicitly name or differentiate 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?

It provides a clear use case — 'Use to assess promoter financial stress and risk' — and flags pledge levels as a governance red flag, which helps an agent decide when this metric is relevant. However, it names no alternative tools and gives no when-not-to-use guidance relative to overlapping siblings like get_shareholding or get_stock_events.

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 destructiveHint, covering safety. The description adds behavioral context: the catalog size (326 ratios) and the distinction between searching and listing. This goes beyond the annotations and helps the agent understand the tool's functionality.

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 sentences, front-loaded with the primary purpose and immediately followed by usage instructions. Every sentence earns its place with no redundancy.

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

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

For a simple tool with one optional parameter and no output schema, the description is complete: it explains what it does, how to use it, and its role in the workflow. It does not describe the return format, but for a lookup tool that is not critical.

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 description covers q at 100% ('Search keyword... Omit for full catalog.'). The description repeats this with additional examples and the exact count, but does not add fundamentally new semantics. Baseline of 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool's function: 'Search or list available financial ratios for the screen_stocks tool.' It specifies the verb (search/list), resource (financial ratios), and context (for screen_stocks), distinguishing it from the screen_stocks tool itself. Examples like 'cash flow', 'debt', 'promoter' further clarify the purpose.

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 provides explicit guidance: 'Use this to find exact ratio names before building a screen_stocks query.' This tells the agent when to use it, but it does not mention when not to use it or contrast with alternative tools. However, the purpose is so specific that the guidance is sufficient.

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 destructiveHint=false, so the safety profile is covered structurally. The description adds useful context about what kinds of holdings are included and the time-series nature of the data, but does not disclose details such as default period handling or whether latest/current values are returned when type is omitted.

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?

Three sentences with no filler: the tool's purpose, the data categories, and a use case are all covered efficiently. The most distinctive information ('over time', 'quarter over quarter') is front-loaded in the first sentence.

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

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

For a read-only data retrieval tool with no output schema, the description conveys the main content and purpose adequately. However, it lacks guidance on how this tool differs from the overlapping sibling get_stock_ownership, and it does not mention the 'Omit for all' period behavior that is only in the schema. These are gaps for an agent deciding whether this is the right 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 100%, so the schema already documents all parameters, including the enum for 'type' and the aliases for 'symbol'. The description adds conceptual context ('over time', 'quarter over quarter') rather than concrete parameter semantics, which is acceptable at the baseline for fully covered schemas.

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

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

The description uses a specific verb and resource ('Get shareholding pattern') and enumerates the content categories (promoter, FII, DII, public holdings). It also adds the distinctive temporal dimension ('over time', 'quarter over quarter'), which helps separate it from the sibling get_stock_ownership even though no sibling is named.

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 a use case ('Track institutional buying/selling trends quarter over quarter') and an application ('understanding ownership changes'), so usage is implied. However, it never states when NOT to use this tool or names alternatives like get_stock_ownership or get_promoter_pledge, leaving the selection decision partly to 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds context about what data is returned (fields, deal types) but does not disclose any additional behavioral traits like rate limits, auth needs, or consequences. It does not contradict the annotations, so a 3 is appropriate—it adds some value but relies on annotations for the safety profile.

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 sentences with zero fluff. The main purpose is front-loaded, and the second sentence adds a concrete use case and a filtering note. Every sentence earns its place, making it highly efficient.

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

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

Given the tool's moderate complexity, a 100% schema-covered parameter set, and the lack of an output schema, the description is sufficiently complete. It explains what the tool does, what it returns, and the optional filter. There is no missing information an agent needs to call it correctly; pagination is already in the schema's limit parameter.

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 parameters (symbol, type, limit, etc.) are already documented with descriptions in the schema. The tool description clarifies the purpose of the symbol (stock) and the type (deal type) but does not add meaning beyond what the schema already provides. Baseline 3 is correct because the schema carries the parameter 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 opens with a specific verb and resource: 'Get large-trade history for a stock' and enumerates the exact deal types (bulk, block, insider, SAST) and fields returned (counterparty, side, quantity, price, value). It answers a concrete question ('who has been buying or selling X?'), which clearly differentiates it from sibling tools like get_stock_news or get_stock_quote.

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

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

The description provides clear context for when to use the tool (when the user wants large-trade/deal history) and mentions the optional filtering by deal type. However, it does not explicitly mention alternative tools or when not to use it, so it falls short of a 5 but is still clear context without exclusions.

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 mark the tool as read-only and idempotent, so the safety profile is covered. The description adds meaningful behavioral details beyond that: news is sentiment-tagged, corporate actions include ex-date and LTP, and filings are sourced from ScanX and Screener with a detailed doc-type list and richer date metadata. This gives the agent a clear picture of what the tool returns.

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

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

The description is well-structured with a one-sentence summary followed by a compact bullet-like list, and the type details are front-loaded and scannable. The 'AFTER using this tool' paragraph is extra agent workflow guidance rather than tool behavior, which slightly dilutes focus, but it does not make the description bloated.

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 multi-type tool with no output schema, the description covers the returned content for each type reasonably well. However, it does not tell the agent how to choose between this tool and the overlapping siblings, and it does not clarify pagination or how the limit parameter interacts with different event types.

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 baseline is 3, but the description adds real meaning beyond the bare enum by explaining what each type value returns: news includes sentiment and source URL, corporate_actions includes dividends/splits/ex-date, and filings enumerates specific document types. This is more than the schema provides, especially for the type parameter.

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

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

The description states a specific action ('Get stock events') and enumerates the three event types with concrete examples, making the tool's purpose unambiguous. However, it does not explicitly distinguish itself from overlapping siblings like get_stock_news, get_corporate_actions, or list_company_documents, so it misses the full sibling-differentiation bar.

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 says 'Filter by type to get only what you need,' which gives a basic selection hint, but it does not explain when to use this tool versus alternatives such as get_stock_news or get_corporate_actions. The 'AFTER using this tool' paragraph advises post-call actions but provides no when-to-use or when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond annotations: the tool delegates to get_stock_events with a preset type filter, and results come back sentiment-tagged. No contradiction between description and 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?

Three short sentences, each earning its place: identity (alias), function (sentiment-tagged news for one stock), and a concrete invocation example. No filler or restatement of annotation values.

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 read-only news tool, the description is nearly complete: purpose, alias behavior, output nature, and a minimal invocation example. There is no output schema, and the description could have said slightly more about what a news item looks like beyond the sentiment tag, but an agent can invoke this correctly from the information given.

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?

All four parameters have descriptions, so schema coverage is 100% and the baseline is 3. The example {"symbol":"TCS"} reinforces symbol as the primary identifier, but it largely duplicates what the schema already provides. Notably, the schema marks symbol as "REQUIRED" while the required array is empty — an internal schema inconsistency the description doesn't resolve, though that is not the description's responsibility.

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?

"Sentiment-tagged news for one stock" states the resource (news), scope (single stock), and output characteristic (sentiment-tagged) with concrete example {"symbol":"TCS"}. The alias note ties it directly to get_stock_events with type:"news", distinguishing it from the broader event tool and from market-wide get_market_news.

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 effectively routes the agent by declaring it an alias for get_stock_events with type:"news", which resolves the ambiguity between the sibling tools get_stock_news and get_stock_events. The "for one stock" scoping implicitly distinguishes it from market-wide news tools. However, it never explicitly names alternatives or states when-not-to-use, so it stops short of full exclusion guidance.

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

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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is content-level behavior. It does add value by describing what the response contains — dividend fields and MF holding fields — which substitutes for the missing output schema. It does not cover edge behavior such as empty holdings or date-range semantics.

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?

Three sentences with zero filler. The core purpose is front-loaded in the first sentence, and the two data sections each get one precise explanatory sentence.

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 read-only tool with fully documented alias parameters and safety annotations, the description covers what the agent needs: the input (symbol) and exactly what data comes back, compensating for the absent output schema. Minor gaps are edge-case behavior and not pointing to sibling ownership tools, but nothing blocks correct invocation.

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

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

Schema description coverage is 100% and all three parameters are fully documented as aliases for symbol. The description adds no parameter-level detail beyond the schema ('for a stock' merely echoes symbol), 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?

Names a specific verb and resource ('Get ownership data for a stock') and enumerates the two concrete sub-parts — dividend history and mutual fund holdings — with field-level detail. This clearly differentiates it from nearby siblings like get_shareholding and get_promoter_pledge, whose ownership scopes differ.

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 field breakdown ('Dividends include ex-date, amount, type... MF holdings show...') implies when this tool is appropriate, but the description gives no explicit when-to-use guidance and never names the competing sibling (get_shareholding). The agent must infer the boundary between ownership 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds that it returns the 'current/latest' quote and lists the metrics, which is slightly more context. However, it does not reveal data freshness, market-hours behavior, or contrast with get_live_quote; the addition is useful but not deep enough to exceed a 3.

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 core sentence is front-loaded and concise. The 'AFTER using this tool' paragraph is an extra block of workflow guidance, which is useful but not strictly about the tool's own behavior; it is clearly labeled and not excessive, so a 4 is appropriate.

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 quote tool with no output schema, listing the fields helps, and annotations cover safety. But given the presence of get_live_quote as a sibling, the description does not disambiguate real-time vs snapshot data, and it omits error or market-hours context, leaving an agent uncertain in edge cases.

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

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

Schema description coverage is 100%; the schema already describes symbol and the ticker/identifier aliases. The tool description adds no parameter-level meaning, so it sits at the baseline of 3.

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 verb–resource pair ('Get the current/latest stock price quote') and enumerates the data fields returned (LTP, change, %, volume, market cap, PE, PB, 52-week high/low). It also explicitly names the sibling get_batch_quotes for the multi-stock case, distinguishing the tool's scope. This exceeds the clear-purpose bar.

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 an explicit when-not: 'For multiple stocks, use get_batch_quotes instead.' It also provides post-call guidance (suggest watchlist, deeper analysis, portfolio update) that directs subsequent tool choices. That's concrete, practical usage guidance beyond the bare minimum.

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 destructiveHint=false, covering the safety profile. The description adds substantial behavioral nuance beyond that: deterministic non-LLM, band vs exact number, null pillars meaning unavailable data, status insufficient_data, caps/red flags, and the deliberate absence of a category label. It also includes disclaimers about decision-support and SEBI registration.

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 long but front-loaded with the core purpose and then structured as a 'HOW TO READ IT' list with numbered points. Each point adds necessary interpretive guidance, so no sentence feels redundant. It is verbose but purposeful, earning a 4 rather than a 3.

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 explain the return value and does so comprehensively: the composite score, six pillars, weights, band, percentile, data-confidence, coverage, and governance flags. It also covers edge cases like null pillars and insufficient_data status. Nothing an agent needs to correctly interpret the result 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?

Schema description coverage is 100%, so all three parameters (symbol, ticker, identifier) are already documented as aliases. The description does not add any additional meaning or usage notes about the parameters beyond what the schema provides, so the baseline of 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 clearly states the verb 'Get', the resource 'Tapetide Score for ONE stock', and enumerates the returned components. It distinguishes itself from the sibling 'screen_tapetide_scores' by explicitly restricting to a single stock, so an agent can tell it apart without ambiguity.

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 explicit use cases ('what is Tapetide's score for X', 'why is X rated Y', rating input for a write-up) but does not mention when NOT to use it or name the alternative screening tool. The 'for ONE stock' phrasing implies the distinction, but there is no explicit exclusion.

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 destructiveHint=false, so the safety profile is fully covered. The description adds useful context about the return scope and temporal nature, but does not disclose details like data freshness, pagination, or response format.

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 the key action and content front-loaded. Every phrase earns its place, and there is no redundant or filler wording.

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, read-only snapshot tool with rich annotations, this description is sufficient. It names the universe (Nifty 500), the categories returned, and the timeframe, so an agent can invoke the tool correctly without additional context.

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

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

The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to clarify about inputs. A baseline of 4 is appropriate since no parameter guidance is needed.

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

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

The description clearly states a specific verb and resource: 'Get trending stock summary' with concrete contents — top gainers, losers, and high-volume stocks — scoped to Nifty 500. This makes the tool's function immediately identifiable and distinct from generic quote or market-data tools.

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

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

The phrase 'Quick snapshot of market movers today' implies when it should be used, giving a temporal and brevity-based context. However, it does not explicitly address alternatives like scan_movers or market_heatmap, nor does it state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, and the description aligns perfectly (a getter, no side effects). It adds behavior beyond annotations by detailing the return contents, handling of empty portfolios, and supported brokers for follow-up, which is critical operational context.

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

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

The description is front-loaded with the core getter purpose and return fields, followed by a structured 'IMPORTANT' usage block. While it is long, each sentence serves a purpose—explaining when to call, what to do with results, and how to handle empty portfolios—so it is not padded or redundant.

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 fully enumerates the data returned, including portfolio weight, sector, and classification. It also covers invocation timing, empty-portfolio handling, and the add_portfolio_stocks integration, making it comprehensive for correct agent behavior in a real advisory workflow.

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 fully covers the input by definition. No parameter explanation is needed; the rubric assigns a baseline of 4 for zero-parameter tools, and the description appropriately skips irrelevant parameter details.

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

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

The description explicitly states 'Get the authenticated user's current stock portfolio with live prices' with a specific verb and resource. It enumerates the returned fields (symbol, sector, P&L, etc.), making its purpose unmistakable and clearly distinct from sibling portfolio tools like add_portfolio_stocks or update_portfolio_stock.

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 includes an explicit directive to call this tool FIRST before any investment advice, with a bulleted list of reasons. It also explicitly names the alternative add_portfolio_stocks when the portfolio is empty and instructs the agent on how to gather holdings data, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the returned data fields and noting that it returns the full set of stocks the user follows, going beyond the structured 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?

The core description is front-loaded in the first sentence, with a clear second sentence on when to use it. The 'AFTER using this tool' paragraph adds navigational value for the agent, though it is slightly beyond what is strictly necessary for invocation, keeping the score from being a 5.

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 zero-parameter read tool with complete annotations and a description that states both the returned fields and the intended usage context. Nothing needed for correct invocation or interpretation is missing, and the follow-up suggestions help the agent plan downstream actions.

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)Skip parameters; the schema coverage is 100% and there is nothing for the description to clarify about inputs. The baseline of 4 applies because no parameter documentation burden exists.

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

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

The description uses a specific verb and resource: 'Get the user's stock watchlist — all stocks they are following.' It also lists the returned fields, making the tool's function unmistakable and distinct from mutation siblings like add_to_watchlist and remove_from_watchlist.

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 a clear trigger: 'Use this to see what stocks the user is tracking before making suggestions.' It does not explicitly name alternatives or exclusions, but the workflow context is strong enough for an agent to know when to invoke it.

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 destructiveHint=false, so the safety profile is covered. The description adds useful behavioral details: ordering ('Newest first') and the nature of the output ('No prose'). It does not contradict annotations, and the added context fills the remaining gap without redundancy.

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 succinct yet information-dense. It front-loads the core purpose, lists output fields, explicitly states 'No prose', and prescribes the calling sequence and alternatives—all in a few sentences. Every sentence earns its place; there is no fluff 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 output schema, the description fully explains what the tool returns (fields, links, formats) and its ordering. It also covers the decision flow (call first, then branch to other tools). For a list/index tool, this is complete and leaves no critical questions unanswered.

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 83% (5 of 6 parameters have descriptions; 'limit' lacks one but has default/min/max). The description does not add any parameter-level semantics beyond what the schema already provides. It focuses on output fields rather than input parameters, so it adds no extra value here. Baseline 3 is appropriate because the schema carries the burden.

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: 'Index of a company's filings parsed to text' and enumerates the output fields (doc_id, type, period, etc.). It also explicitly says 'No prose' and names the follow-up tools (get_document_summary, read_document), which distinguishes it from siblings that return actual content. The purpose is specific and 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 gives explicit usage guidance: 'Call first.' and then prescribes next steps: either use get_document_summary/read_document for text, or hand a link/download to search locally. This clearly tells the agent when to use this tool and how to proceed, which is more than most descriptions provide.

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 destructiveHint=false, covering the safety profile. The description adds useful context about the response content (fields included) but does not disclose any additional behavioral traits such as pagination, rate limits, or output size. Given the annotations carry the safety burden, a 3 is appropriate for the value added.

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

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

The description is concise: two sentences. The core functionality is front-loaded in the first sentence, and the second clarifies the available index options. It is efficient, though the second sentence could be shortened by relying more on the schema, but it is not wasteful.

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 a single optional parameter fully described in the schema, no output schema needed, and the description clarifies the response scope (all constituents with specified metrics). It is complete for an agent to call correctly, including the default index value. Nothing essential 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?

Schema description coverage is 100%: the 'index' parameter is fully documented with the default value and the complete list of allowed slugs. The description merely points to the parameter ('see the index parameter'), adding no extra semantic meaning beyond what the schema already provides. Baseline 3 is correct.

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: 'Get a stock heatmap for an index' and enumerates the exact data fields returned (market cap, PE, PB, price changes, volume, sector). This is a precise and differentiated purpose, clearly distinct from sibling tools like get_index_performance or get_index_history which focus on index-level data.

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

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

The description implies when to use this tool: when you need a constituent-level snapshot for an index. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to infer it is the right choice for heatmap-style data. No misleading guidance is present.

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 destructiveHint, covering the safety profile. The description adds useful behavioral context: default weekly data frequency, default 5-year period, and the flexible index_code format. No contradiction with annotations, but it doesn't describe response format or pagination, which are minor gaps given the annotation coverage.

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 and well-structured. The first sentence front-loads the purpose and defaults, and the second paragraph efficiently explains the parameter format without repetition. No wasted words, and every sentence serves a purpose.

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

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

For a read-only tool with two optional parameters, the description covers the essential information: what it returns, defaults, and parameter format. It lacks explicit mention of the response structure (e.g., time-series format), but given the tool's simplicity and absence of an output schema, this is not a critical omission. The description is adequate for an agent to call 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 100%, providing a baseline of 3. The description adds value by explicitly mapping each slug to its numeric code (e.g., nifty-50 (13)) and clarifying that index_code accepts either form. This goes beyond the schema's description, which lists only slugs, so the description meaningfully enhances 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 the tool retrieves index valuation metrics (PE, PB, Dividend Yield) over time, with specific defaults. It is specific about the resource and purpose, but it does not explicitly differentiate from sibling tools like get_index_history or market_heatmap, so it falls short of a 5.

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

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

The description includes a use case ('assessing whether the market is overvalued or undervalued relative to historical averages') but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. The usage is implied rather than explicitly contrasted with siblings.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds valuable behavioral context: pagination limits (12 pages/24000 chars), result fields (pages_returned, next_pages), and links to full Markdown/PDF. This is genuine added value beyond the 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?

The description is compact: three sentences, front-loaded with the core function, then limits, then a practical usage tip. Each sentence earns its place and there is no redundant or fluffy text. It is well-structured for quick 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?

Given the tool's simplicity and the rich annotations, the description covers the essential context: what it returns, limits, pagination, and advice for large documents. It lacks explicit error handling or a full return structure, but those are minor given the annotations and schema. Overall, it is sufficiently complete for an agent to call 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 83%, meaning most parameters are already documented. The description reinforces max_chars behavior and mentions doc_id's source, but does not add substantive new semantic meaning beyond the schema. Since the schema carries the load, a baseline of 3 is appropriate.

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

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

The description clearly states it provides Markdown text of a parsed filing by doc_id and page range, with page markers for citation. This is specific and distinct from other document-related siblings like list_company_documents or get_document_summary, though it does not explicitly name them. The purpose is 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?

It gives concrete guidance for large filings (100-400 pages) — read only needed sections or download the Markdown link to search the whole file. It also sets expectations about page/character limits per call. While it doesn't explicitly contrast with alternative tools, it provides sufficient context for when and how to use it.

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?

The annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe. The description adds the behavioral fact that this is a meta-tool (returns a guide), not a data operation, and signals an expectation of high importance ('IMPORTANT'). It does not describe output format or length, but given the no-parameter, no-side-effect nature, the description provides adequate context.

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

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

The description is a single sentence but dense; it front-loads the critical directive ('Call this FIRST') and packs in the key contents. It is efficient with no fluff. It could be slightly more structured (e.g., bullet points) but for a short description 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?

For a no-parameter, read-only tool, the description covers the essential context: what the tool does, why it matters, and what it contains. It doesn't specify return format or length, but as a guide, those details are likely evident from the content. Given the rich sibling list and the tool's meta-role, the description sufficiently prepares an agent to call it first and understand its purpose.

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 0 parameters, so there is no schema to explain. The description correctly focuses on what the tool returns rather than any input semantics. With parameter count 0, the baseline for this dimension is 4, and the description does not introduce any confusion. It clearly sets expectations for output content.

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

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

The description clearly states that the tool returns a complete guide organizing all tools by category, with critical rules and usage patterns. It identifies the resource ('complete guide') and the action ('returns'), and its purpose as an orientation/onboarding tool. It does not explicitly name a sibling to differentiate from, but its role as an index is distinct enough from the data-retrieval 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?

The description explicitly instructs 'Call this FIRST', which is strong when-to-use guidance. It also lists what the guide includes (rules, patterns, cross-tool suggestions), which implies it should be consulted before using other tools. It doesn't mention when not to use it, but the 'FIRST' directive is clear and compelling.

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 disclose destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds little behavioral context beyond the obvious fact that symbols are removed, so it does not carry much extra burden.

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 and front-loaded with the core action, followed by two relevant use-case bullets. There is no filler or redundant restatement of structured fields.

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

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

For a simple one-parameter mutating tool, the description covers the action, the single-removal case, and the clear-all workflow requiring get_watchlist. Combined with the schema and annotations, nothing essential is missing for an agent to call 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 100%, and the schema already documents the symbols array with examples. The description reinforces the example use cases but does not add meaningful parameter semantics beyond the schema.

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

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

The description opens with 'Remove one or more stocks from the user's watchlist,' which states a specific verb, resource, and scope. This clearly distinguishes it from siblings like add_to_watchlist, get_watchlist, and remove_portfolio_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 use cases provide concrete trigger phrases for single removal ('Stop watching INFY') and full clearing ('Clear my watchlist'). It also gives the necessary prerequisite for clearing all symbols: get watchlist first. It does not explicitly name alternatives or when not to use this tool, but the context is clear.

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

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

Annotations already expose destructiveHint=true and idempotentHint=true, but the description adds valuable process context: the action cannot be undone and user confirmation is required before removing symbols. It also clarifies the 'entirely' removal scope, which goes beyond the annotation flags.

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 front-loaded with the core purpose, then uses compact bullet examples to illustrate concrete triggering phrases. Every sentence earns its place, and the critical safety warnings are prominently included without redundancy.

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

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

For a simple one-parameter destructive tool, the description covers the key operational points: confirmation, irreversibility, scope, and routing. It does not specify response shape or behavior for already-absent symbols, but with no output schema and such a focused operation, the remaining 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 for the single symbols parameter is 100%, with min/max constraints and an example provided. The description does not need to re-explain the schema and adds only incidental context about deriving symbols from get_user_portfolio, so the baseline score 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 action ('Remove one or more stocks from the user's portfolio entirely') with the resource clearly named. It also differentiates itself from update_portfolio_stock by explicitly noting that partial sells should use that sibling tool.

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 explicit use cases covering single delete, bulk semantic deletion, and clearing the entire portfolio. It instructs the agent to confirm with the user before acting and routes partial sells to update_portfolio_stock, giving clear when-to-use and when-not-to-use guidance.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), the description discloses the return statuses ('present' | 'uncertain' | 'not_found' | 'out_of_coverage'), the meaning of 'uncertain' (open bracket around rename), and the coverage window behavior. This is valuable behavioral context not covered by 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?

The description is well-structured, starting with the core purpose, then usage context, then response semantics. It is somewhat long but every sentence adds value. The front-loading of the purpose is good, and the format is readable. Slightly verbose but not wasteful.

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

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

Given the complexity of as-of resolution (renames, recycles, coverage windows) and the absence of an output schema, the description covers all critical aspects: return statuses, the uncertain bracket, coverage window, and handling guidance. Nothing essential is missing for an agent to call 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 descriptions cover all three parameters (date, kind, value) at 100% coverage, so the baseline is 3. The description adds some context (e.g., examples 'TRENT' or 'INE849A01020') but does not provide additional parameter-level semantics beyond what the schema already states. It reinforces the schema but doesn't add new 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 verb ('Resolve') and resource ('historical symbol or ISIN') with an explicit temporal scope ('ON a given date'). It clearly differentiates from generic lookup tools by explaining the as-of resolution and mentions the edge cases of renames/reassignments, which distinguishes it from sibling tools like get_identifiers_asof without naming them.

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 explicit when-to-use guidance ('USE THIS when working with old data...') with concrete examples (2018 holdings, old research notes, backtests). It also gives behavioral instructions for handling the response: quarantine uncertain results and do not report out_of_coverage as 'no such symbol'. This is comprehensive usage 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 establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the crucial behavioral context that this is not a standalone operation and that its parameter is ignored, reinforcing that calling it is a no-op redirect.

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

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

One sentence front-loads the most important fact ('Not a standalone tool') and then delivers the routing alternatives without any filler. Every clause 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 redirect stub, the definition is complete: it tells the agent not to use the tool, names the correct alternatives, and confirms the input is ignored. No output schema is necessary because the tool has no meaningful output to describe.

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 covers the single parameter 'preset' with 'Ignored — see the redirect message,' so the parameter's semantics are fully documented. The tool description itself adds no parameter detail, but none is needed because the parameter has no effect; this aligns with the schema-coverage 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?

The description immediately declares 'Not a standalone tool' and enumerates the exact alternatives (get_trending_stocks, screen_stocks, screen_stocks_technical), making it clear this is a redirect stub rather than a real screen runner. It distinguishes itself from the sibling screening tools with concrete conditions.

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 explicit routing logic: use get_trending_stocks for ready-made movers, screen_stocks for custom fundamental screens, and screen_stocks_technical for technical screens. An agent knows exactly when to choose an alternative and which one fits the user's intent.

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 destructiveHint=false, so the safety profile is covered. The description adds behavioral context by specifying the output content (gainers, losers, most-active), which is beyond the annotations. It does not mention rate limits or other operational details, but for a read-only alias this is acceptable.

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

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

The description is two sentences with zero filler. It leads with the alias declaration and immediately follows with the output summary. Every word serves a purpose, and it is appropriately 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 parameterless alias tool with robust annotations, the description fully covers what it is and what it returns. No output schema is present, but the description succinctly describes the result set. There is nothing missing that an agent needs to call 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?

The tool has zero parameters, so schema coverage is trivially 100% and there is nothing to document. The baseline for 0 parameters is 4, and the description does not need to add any parameter semantics since there are none. It correctly omits any parameter talk.

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

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

The description explicitly states it is an alias for get_trending_stocks and enumerates the exact content: top gainers, losers, and most-active stocks. This is a specific verb-resource pair with clear output scope, and it immediately distinguishes itself from all siblings by naming the canonical tool it mirrors.

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

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

The description provides clear context by declaring it an alias for get_trending_stocks, making usage unambiguous—the agent knows to treat it exactly like that sibling. However, it does not explicitly state when to prefer this alias over the original or any conditions, though the alias nature makes that implicit. It lacks an explicit 'use this instead of' but is still quite clear.

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 the tool read-only, idempotent, and non-destructive. The description goes further by disclosing query syntax constraints, the 1500-character limit, exact ratio-name matching, cross-field comparison allowance, and the meaning of 'last year'. No contradiction with annotations 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?

The description is dense but well-organized with clear sections for query syntax, common ratio names, and an example. Every sentence contributes practical value, with no filler or repetition of the schema.

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 a nontrivial query language and 326 possible ratio names, the description provides everything needed to invoke it correctly: syntax, allowed operators, connectors, examples, exact-name requirement, and fallback routes. The lack of an output schema is not a gap for this selection-use case.

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

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

All six parameters already have schema descriptions, so the baseline is 3. The description raises this by providing query grammar, operators, connectors, an example, and a list of common ratio names, substantially enriching the meaning of the query parameter beyond the schema.

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

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

The description states a specific verb ('Screen'), resource ('Indian stocks'), and scope ('by fundamental criteria using 326 financial ratios'), and explicitly distinguishes itself from screen_stocks_technical. An agent can immediately tell what this tool does and how it differs from the closest sibling.

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 explicit routing instructions: use screen_stocks_technical for technical screens, call get_screener_ratios for unknown ratio names, and call read_me for disambiguating unknown stocks. This is clear when-to-use and when-not-to-use guidance with named 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?

Annotations already cover read-only, idempotent, and non-destructive safety. The description adds contextual behavior: data is real-time, crossovers are 'crossover today', filters combine with AND logic, and market_cap_basic is in absolute rupees rather than crores. This meaningfully extends beyond the 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?

The description is dense but organized: purpose, alternate tool, filter syntax, operations, fields, unit warning, and example. It is front-loaded with the core action and routing, and the long field enumeration is directly necessary for correct invocation. No filler sentences exist, though it could be tighter if a reference document were available.

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

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

With no output schema, the description should explain what the tool returns. It never describes the response shape, default columns, or result container, which is a clear gap given the columns and limit parameters. The extensive input guidance makes it adequate, but the missing output semantics prevent full completeness.

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 80%, establishing a baseline of 3. The description significantly enriches parameter understanding by defining the filter object shape, enumerating all operations (including in_range and crossover semantics), providing a full field vocabulary, and giving a concrete example. The only minor inconsistency is marking filters as REQUIRED while the schema does not enforce this, but the added detail still outweighs that.

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 action — 'Screen Indian stocks by technical indicators' — and names the resource (real-time Indian stock data). It explicitly lists indicator families (RSI, MACD, moving averages, crossovers, volume, momentum) and distinguishes itself from screen_stocks, making the tool’s scope unmistakable.

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 provides an explicit routing rule: for fundamental screening (PE, ROCE, Sales, Growth), use screen_stocks instead. This directly answers when to use this tool versus its sibling, going beyond implied usage to a clear directive with an example.

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