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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about latest-price valuation, benchmark comparison, and risk flagging, but does not discuss data freshness, external service dependencies, or rate limits beyond what annotations imply.

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 purpose and structured into purpose, Args, and Returns sections. It is efficient overall, though the Args and Returns sections partially repeat information already available in the schema and output 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 complex portfolio-analysis tool, the description covers the input concepts and the major output areas (holdings, allocation, risk, performance, flags). With an output schema present and annotations covering safety, the remaining gap is minor: it does not mention data limitations or error behavior.

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

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

Schema description coverage is 100%, so the schema already documents holdings, benchmark, response_format, and nested Holding fields. The description's Args section largely mirrors that information and adds no new syntax or constraints 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 and resource: it analyses an Indian equity portfolio, then enumerates valuation, P&L, concentration, technical signals, benchmark risk metrics, and risk flags. This clearly distinguishes it from sibling tools that fetch single-stock or market-wide data.

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

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

The opening sentence and workflow give clear context for when to use the tool: portfolio-level analysis. It does not name explicit alternatives or exclusions, but the scope is sufficiently clear that an agent can select it for portfolio analysis versus single-stock 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine value by disclosing the composite data sources (latest quote, headline fundamental ratios, technical signal score) that get assembled into each row. It omits error handling for invalid symbols or partial failures, which keeps it from a 5.

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

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

Front-loaded with the core purpose in the first line, followed by a concise explanation of what is assembled. The Args/Returns block duplicates the schema slightly, but the overall length is proportionate and no sentence is wasted.

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

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

An output schema exists and the description correctly states the return shape (markdown table or JSON list, one row per symbol), so return values need no further detail. Given rich annotations and full param coverage, the only gap is behavior on invalid or missing symbols.

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 Args block essentially restates the schema (including the NSE/company-name allowance and the markdown/json enum). Baseline 3 applies since the schema already carries the 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?

States a specific verb ("Compare") and resource ("two to five Indian stocks") plus the four dimensions covered: price, valuation, quality, momentum. This clearly separates it from single-symbol tools like get_quote or get_fundamentals, though it never names those siblings explicitly.

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

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

The "two to five" cardinality constraint implicitly tells the agent not to use this for a single symbol, and the dimension list hints at the comparison use case. However no alternatives are named and there is no explicit when/when-not guidance versus screen_stocks or get_valuation.

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 non-destructive, so the safety profile is covered. The description adds genuine context beyond that: exactly which line items come back from each of the three statements and that results span the requested number of periods. It omits data source, currency, and latency, which keeps it from a 5.

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

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

Front-loaded purpose sentence, then a compact enumeration of returned fields, then Args and Returns blocks. Every sentence carries information and the structure mirrors how an agent searches for a 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?

For a read-only data-fetch tool with annotations covering safety and an output schema present, the description is nearly sufficient. Minor gaps remain around market scope (NSE-only, currency) and whether periods align to fiscal year ends.

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 schema already documents all four parameters including the 1-10 range for years and the enum for response_format. The Args block largely restates those descriptions, adding only the NSE-market hint and the 'number of periods' framing; 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?

Specific verb + three named resources (income statement, balance sheet, cash flow) with an explicit enumeration of the line items returned, which distinguishes it from sibling tools like get_valuation and get_fundamentals. It stops short of explicitly naming those siblings as alternatives, so it is clear but not fully differentiated.

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

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

Usage is implied by the field enumeration and the Args block (NSE symbol, annual vs quarterly), but there is no explicit 'use this when...' or 'use get_valuation instead for ratios' guidance. The agent must infer the boundary from the listed fields.

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, openWorldHint and non-destructiveness, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that India-specific ratios come from the external Screener.in source — but says nothing about latency, coverage gaps for non-Indian tickers, or failure modes when metrics are unavailable.

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

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

Front-loaded with the core purpose, then cleanly sectioned into Args and Returns. The metric enumeration is long but earns its place by letting an agent know whether a needed ratio is present; the Returns block partially duplicates the output schema, which is the only real 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?

With an output schema present and full schema coverage, the definition supplies everything needed to invoke correctly, plus useful scope information about what the payload contains. Missing only guidance on symbol resolution and on behavior for non-Indian or invalid symbols.

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 three parameters including the Screener.in flag and the enum-constrained response_format. The Args block restates that information without adding format, normalization, or fallback semantics, so baseline 3 applies.

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

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

States a specific verb and resource ('Get a full fundamental picture of an Indian stock') and enumerates the metric families returned, which makes it distinguishable from narrower siblings like get_valuation and get_financial_statements by scope. However, it never names those siblings or states that this is the aggregate view, so the differentiation is inferred rather than explicit.

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

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

Usage is only implied: an agent can infer this is the broad fundamentals call versus the narrower valuation/statements tools, but there is no explicit 'use this when…/use X instead when…' guidance and no prerequisites (e.g., symbol lookup via search_symbol) are mentioned.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the response shapes (markdown table or JSON list) and the existence of a default index set, but says nothing about latency, rate limits, or what happens when a requested index name is unknown.

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?

Front-loaded with the core action, then the coverage list, then usage, then Args/Returns. No filler sentences; the index enumeration is long but it is the substantive scoping information an agent needs.

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?

A zero-required-parameter read tool with 100% schema coverage, full annotations, and an output schema – nearly everything necessary is present. The Returns section duplicates what the output schema already encodes, which is mildly redundant rather than harmful.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, including the example of index name formatting and the default-set behavior. The description's Args block largely restates this ('optional list of index names', "'markdown' or 'json'") without adding format or edge-case details, 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?

Specific verb + resource ('Get live quotes for major Indian indices') with an explicit enumeration of the covered universe (NIFTY 50, SENSEX, sector indices, INDIA VIX). That universe listing makes it trivially distinguishable from siblings like trademcp_get_quote (single symbol) or trademcp_get_market_breadth.

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

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

Usage is only implied by 'so the caller can see where the market stands' – a broad market-overview framing. It never states when to prefer this over trademcp_get_quote or trademcp_get_market_breadth, nor any prerequisites. The one concrete usage instruction is parameter-level ('Omit for the default set').

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

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

Annotations already declare readOnly, idempotent, destructive=false and openWorld. The description adds genuine behavioral detail beyond that: the trend calculation is 'slower' (a latency signal) and precisely what statistics are produced. It doesn't discuss rate limits, error behavior, or index validity handling.

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 opening sentence front-loads the purpose and the body enumerates outputs efficiently. The Args/Returns blocks are partly redundant with the fully described schema and output schema, slightly diluting conciseness.

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

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

With an output schema, complete annotation coverage, and 100% parameter documentation, the description is sufficient to call the tool correctly. The only missing element is guidance on picking this tool over sibling analysis tools.

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 all three parameters are already documented, including the 'slower' caveat on include_trend and the JSON/markdown enum. The Args section largely restates the schema, adding no new syntax, defaults, or constraints, so baseline 3 applies.

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

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

States a specific verb (measure) and resource (market breadth for an Indian index) and enumerates the concrete outputs: advancers/decliners, average and median move, gainers/losers. It does not contrast itself with adjacent siblings like get_index_snapshot or get_technical_analysis, 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?

Usage is implied by the description of what it computes, and 'Optionally adds ... the classic trend-breadth gauge' gives some context for include_trend. There is no explicit when-to-use, when-not-to-use, or named alternative among the 13 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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), but the description adds real value beyond them: newest-first ordering, the period start/end prices and total return, and the two response formats with their return shapes. It does not mention data recency or rate/source limits, which matters given openWorldHint=true.

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?

Purpose and return shape are front-loaded, which is good, but the six-line Args block duplicates parameter documentation the schema already provides in full, so several sentences do not earn their 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?

With an output schema present and full parameter documentation, the definition covers what an agent needs to call it correctly. Minor gaps remain around data freshness and how range interacts with limit, neither of which is stated.

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 bar is baseline 3, and the Args block largely restates the schema ('range: lookback window', 'interval: candle size') without adding meaning such as allowed enum values or interaction rules between range and limit.

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 ('Get historical OHLCV candles for an Indian stock') and the word 'historical' cleanly separates it from the point-in-time siblings such as trademcp_get_quote and from indicator tools like trademcp_get_technical_indicators. An agent can route on this sentence alone.

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

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

Usage is only implied via 'so the caller can chart or analyse the series'; there is no explicit when-to-use, when-not-to-use, or named alternative such as 'use get_quote for the current price'. An agent must infer the boundary itself.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description contributes one genuinely useful behavioral detail — an 'Error: ...' string when the symbol cannot be resolved — but says nothing about data latency/real-time-ness, rate limits, or upstream data source, which matter for an openWorld quote tool.

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

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

Well front-loaded: purpose in sentence one, payload in sentence two, then Args/Returns blocks. There is some redundancy where the Returns section repeats the enumerated fields already listed in the opening, but overall it is tight and skimmable.

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?

An output schema exists, so re-describing the return payload adds little, while the real gaps — sibling differentiation, whether the quote is real-time or delayed, and exchange-selection semantics — go unaddressed. Adequate to call the tool correctly, but not complete for a 13-sibling financial data suite.

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 contains examples ('RELIANCE', 'tata motors') and defaults for exchange and response_format. The Args block largely restates the schema verbatim without adding syntax, normalization rules, or fallback behavior for exchange, so baseline 3 applies.

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

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

The first sentence names a specific verb and resource ('Get the latest price quote and key statistics for an Indian stock') and the body enumerates exactly what is returned, so an agent knows this is a current-snapshot tool. It does not, however, distinguish itself from siblings like trademcp_get_valuation or trademcp_get_price_history even though the listed return fields (P/E, P/B, returns) overlap with 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?

There is no explicit statement of when to use this versus the 13 sibling tools — no mention that historical data belongs to get_price_history or that deep valuation belongs to get_valuation. The snapshot nature is only implied by the word 'latest', leaving the agent to infer routing from the return-field list.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is a computation over Indian stock data and lists the analytical outputs, but it does not disclose data freshness, rate limits, authentication needs, or error behavior.

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

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

The description is front-loaded with the core purpose and uses a clear Args/Returns structure. It has minor redundancy because the output components are enumerated in prose and then partially repeated in the Returns section, despite an output schema also being present.

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 gives enough context to understand that this is a read-only technical computation for Indian NSE stocks and what analytical outputs to expect. It is complete for invocation, though it could better explain when to choose this tool over related technical-analysis siblings.

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

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

Schema description coverage is 100%, so the schema already documents symbol, range, and response_format. The description repeats those parameters at a high level but adds no meaningful syntax or format detail beyond the schema, making the baseline 3 appropriate.

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

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

The description uses a specific verb and resource: "Compute support and resistance levels for an Indian stock." It clearly enumerates the computed outputs, but it does not explicitly distinguish this tool from siblings such as trademcp_get_technical_indicators or trademcp_get_technical_analysis.

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

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

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. Usage is only implied by the stated purpose, and none of the sibling technical-analysis tools are referenced 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 cover safety (readOnly, idempotent, non-destructive), so the description's job is to add context, and it does: it names the exact composite scale (Strong Buy through Strong Sell) and the specific risk metrics computed (volatility, Sharpe, Sortino, max drawdown, beta, alpha, 30-day relative strength). It does not disclose data source, latency, or whether results are cached, which keeps it short of a 5.

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

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

Front-loaded: the first sentence says what the tool produces, then the Returns/Args blocks. Every sentence carries information, though the Args section is mildly redundant with an already fully-documented 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?

An output schema exists, yet the description still summarizes the return keys ('summary', 'signals', 'indicators', 'statistics', 'candles'), and it covers all four inputs with defaults. For a read-only analysis tool, an agent has everything needed to call it correctly and interpret the shape of the result.

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 all four parameters are documented in the schema itself, so the baseline of 3 applies. The Args block largely restates the schema ('symbol: NSE symbol or company name', 'response_format: markdown or json') without adding format, constraints, or behavior — for example, what happens if the symbol is ambiguous or unknown.

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 ('Run a full technical analysis') and enumerates the concrete outputs: indicator scores, composite rating, risk statistics, candlestick patterns. It is clearly a composite-analysis tool, distinguishing it in substance from trademcp_get_technical_indicators, but it never names that sibling or explicitly contrasts the two.

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

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

Usage is implied by the output inventory — an agent can infer this is the 'give me the whole technical picture' call. However, there is no explicit when-to-use, when-not-to-use, or routing statement pointing to get_technical_indicators, get_support_resistance, or get_price_history.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the two response shapes (markdown table of latest + recent values, or JSON with 'indicators' and 'series'), which is useful context, but says nothing about data source freshness, rate limits, or the cost of computing all 60+ indicators.

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 opening two paragraphs are well front-loaded and earn their place. However, the Args and Returns blocks largely duplicate the 100%-covered input schema and the existing output schema, so a meaningful share of the text is redundant rather than additive.

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 6 parameters, full schema coverage, an output schema and rich annotations, the definition supplies what an agent needs to invoke the tool correctly. The remaining gap is routability against trademcp_get_technical_analysis and trademcp_get_support_resistance, which the description never addresses.

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 earns the bump because the enumerated indicator taxonomy (trend/momentum/volatility/volume/statistics with named examples) helps an agent actually construct the otherwise free-form 'indicators' array beyond the schema's two examples. The Args section otherwise restates the schema verbatim for symbol, range, interval, limit and response_format.

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 ('Compute technical indicators for an Indian stock') and enumerates the indicator families covered, which makes the tool's scope concrete. It stops short of distinguishing itself from the closely-named sibling trademcp_get_technical_analysis or get_support_resistance, so an agent still has to guess which of the three to reach for.

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

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

Usage is only implied: 'omit for the full set' and the category list tell you how to use parameters, but there is no explicit when-to-use-this-vs-alternatives guidance despite three overlapping siblings. No preconditions, no exclusions, no routing 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that: it discloses the response sections ('valuation', 'growth_context', 'verdict', optional 'peers') and that a plain-English cheap/expensive verdict is computed, which the agent could not know from annotations alone.

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 opening sentence is front-loaded and delivers the purpose immediately, and the metric list is dense and useful. The Args/Returns blocks duplicate the input schema and output schema, which is mild waste but standard for this format.

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 an output schema present, the description still helpfully names the return sections, and it scopes the tool to Indian/NSE stocks, which is important context. Minor gaps: no mention of data freshness, caching, or whether non-NSE symbols are rejected.

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 Args block largely restates what the schema already says ('symbol: NSE symbol or company name', 'response_format: markdown or json'). The 'peers' note adds a small amount of meaning (same-industry comparison) but nothing beyond the schema's own 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?

States a specific verb and resource ('Get a focused valuation sheet for an Indian stock') and enumerates the exact metrics returned, so an agent knows precisely what it gets. It does not explicitly differentiate itself from the closely related trademcp_get_fundamentals sibling, leaving that overlap for the agent to infer.

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 word 'focused' and the enumerated valuation metrics imply this is the narrow valuation-only view, but there is no explicit 'use this instead of X when Y' guidance. With siblings like get_fundamentals and compare_stocks in the same family, an agent must guess which 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 declare readOnly/idempotent/non-destructive and open-world, so safety is covered. The description adds real behavioral detail beyond that: the two-stage filter order (fundamentals first, technicals on survivors) and that both matches and the applied filter set are returned. It omits expected latency/result-size implications of scanning the full NSE universe.

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 opening paragraph is well front-loaded and earns its place. However, the 19-line Args block restates parameters that are already 100% documented in the schema, adding bulk without new meaning.

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?

Output schema exists and annotations cover safety, so the description need only explain the process — which it does. The main residual gap is the ambiguous P/E parameter wording and the absence of any note on scan cost/results for large universes.

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 would be 3, but the description actively muddles two parameters: it says 'min_pe: maximum P/E' and 'max_pe: minimum P/E', which conflicts with the schema's own (already inverted-looking) descriptions. An agent reading both would have to guess the direction of the P/E filter, which is a real error risk.

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 ('Screen Indian stocks by fundamental and technical criteria') and the pipeline (index/NSE scan → fundamentals → technical filters). Among siblings that fetch single-company data, this is clearly the only multi-name screening tool, so differentiation is immediate.

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

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

Usage is implied by the description's screening framing, but there is no explicit statement of when to reach for this instead of get_fundamentals or compare_stocks, and no guidance on universe cost trade-offs (e.g., 'NSE' scans everything).

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuine behavior: matches are ranked with exact symbol matches first, which tells the agent how to interpret ordering and that fuzzy matches are possible.

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 opening two sentences are front-loaded with purpose and the selection condition, which is the highest-value content. The trailing Args and Returns blocks duplicate the input schema and output schema respectively, adding length without new 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?

An agent knows what the tool does, when to reach for it, how results are ranked, and what fields come back. With an output schema present, the Returns section is redundant rather than necessary, and no note on empty-result behavior is included, so it falls just short of fully 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 coverage is 100% and every schema parameter already carries a description with examples and the 1-50 range. The Args block essentially restates the schema (query, limit, response_format) without adding syntax, matching semantics, or format details beyond it, 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?

States a specific verb (search) and resource (NSE-listed companies) with the two acceptable key types (ticker or company name). The scope makes it clearly a symbol-resolution tool, distinct from the sibling data-fetching tools like trademcp_get_quote or trademcp_get_fundamentals.

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 names the trigger condition: use when the user supplies a company name instead of an NSE code, or when the symbol may be ambiguous. It implies the inverse (skip if you already have the code) rather than stating it, and names no alternative tool, keeping it short of a 5.

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