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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is covered. The description adds useful context about the kinds of data returned and the available view modes, but does not disclose data freshness, rate limits, or other behavioral constraints 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 and front-loads the main content categories without filler. It is a sentence fragment rather than a complete statement, but every element contributes useful information.

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

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

With no output schema and no parameter descriptions in the schema, the description should do more to explain return structure and view-mode behavior. It adequately lists the content categories an agent can expect, but leaves gaps around output shape, view semantics, and sibling differentiation.

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

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

Schema description coverage is 0%, so the description must compensate for parameter documentation. It usefully lists the allowed values for 'view' (auto | consolidated | standalone), but it does not explain what those modes mean or clarify the required 'symbol' parameter beyond its 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 clearly identifies the resource as a company overview and enumerates the major data domains it covers: ratios, about, sector/industry, pros/cons, and compounded growth. However, it has no explicit verb and does not distinguish this tool from overlapping siblings such as company_snapshot or financial_statement.

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 no guidance on when to use this tool versus alternatives like company_snapshot or financial_statement. The only usage-like detail is the 'view' parameter options, which belongs to parameter semantics rather than tool selection.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds real value on top: it discloses that everything comes back in a single request and that red-flag checks are deterministic. It says nothing about latency, payload size, or behavior for an unknown/invalid symbol.

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 lines, front-loaded with the 'best first call' recommendation, then the payload contents, then the parameter format. Every clause carries information; nothing is repeated from the schema or annotations.

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 say what comes back, and it does by enumerating the eight payload components. Combined with the parameter format and the read-only annotations, an agent has everything needed 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 0% with a bare 'symbol' string, so the description must carry the burden and does: it specifies NSE symbols (TCS) or BSE numeric codes (500570) with examples for both formats. Without this the agent would have no idea which identifier convention to use.

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

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

States a specific resource (a bundled company snapshot) and enumerates exactly what one call returns: ratios, sector, pros/cons, growth, earnings trend, red flags, shareholding, documents. 'Best first call' also distinguishes it from the narrower siblings like company_overview or red_flags, which cover only slices of this bundle.

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?

'Best first call' gives a clear usage context: start here before reaching for the narrower tools. It stops short of naming which siblings to skip or when to prefer company_overview/earnings_trend directly, so the routing guidance is implied rather than explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so safety is covered. The description adds the meaningful 2–6 company constraint, but does not disclose what happens outside that range, how results are ordered, or any failure 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?

A single, front-loaded sentence that names the operation, the metrics, and the scope with no wasted words. It is efficient, although the extreme brevity leaves gaps that could be closed in one additional clause.

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?

No output schema exists, and the description partially compensates by naming the four metric categories returned. With only one simple parameter and full annotation coverage, this is adequate, but missing symbol-format guidance and error/edge-case behavior keep it from being 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 0% and the single parameter is undocumented, so the description must compensate. It does add the important 2–6 item constraint on the symbols array that the schema lacks, but it never states the symbol format (tickers vs. names) or ordering expectations, leaving meaningful ambiguity.

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

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

The description states a specific operation (side-by-side comparison) and enumerates the covered dimensions (valuation, returns, margins, growth) plus the 2–6 company scope. An agent can tell what it does, though it does not explicitly distinguish itself from the sibling 'peers' tool, which is the nearest alternative.

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

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

Usage is implied by the 'side-by-side' framing and the 2–6 company range, which signals multi-company comparison rather than single-company lookup. However, no explicit when-to-use/when-not guidance or pointer to alternatives like 'peers' or 'company_snapshot' is given.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds that the output is links to external documents rather than the documents themselves, which is useful context. It does not say what happens with kind=all (how many per category), how limit interacts with categories, or whether recent-only results are returned.

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 compact sentences: one for the resource, one for the kind enumeration. Front-loaded and waste-free, though the enum sentence is dense and 'concall' is unexpanded jargon that a non-finance agent may not 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?

There is no output schema, and the description only hints at return values ('links to...'), without saying whether items include titles, dates, or URLs grouped by category. With 0% schema description coverage on three parameters, an agent must guess at symbol format and limit semantics. Adequate to identify the tool, but thin for 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 0% and the schema has no enum on `kind`, so the description carries real weight by enumerating the allowed kind values (all, announcements, annual_reports, credit_ratings, concalls) – that information exists nowhere else. However, `symbol` format and the meaning/behavior of `limit` (default 20, max? pagination?) are left entirely undocumented.

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 concrete resource: links to exchange announcements, annual reports, credit ratings and concall transcripts/presentations/recordings. This is clearly distinct from the sibling tools, which are numeric/analytical (financial_statement, earnings_trend, peers), so an agent can tell this is the document-link lookup tool. It stops short of a full verb phrase like 'Fetch links for a given company symbol', hence 4 not 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 list of document categories implies when the tool is useful (when the user wants filings, ratings or call material rather than numbers), but there is no explicit 'use this when...' statement and no mention of any alternative tool. Usage is inferable but not guided.

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 value by disclosing that a computed classification (accelerating/steady/decelerating) is returned, but it says nothing about history depth, missing-data behavior, or cost of a call.

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

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

One dense sentence with the return content front-loaded and no filler. It is efficient, though the absence of any parameter clause means the brevity is partly achieved by omission rather than by tight writing.

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 does a reasonable job naming the return fields, which is the main burden here. However, for a two-parameter tool with zero schema documentation, omitting the quarters window leaves the agent unable to control or predict the result span.

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

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

Schema coverage is 0%, so the description must carry parameter meaning, and it does not mention either parameter. The 'quarters' input with its default of 8 is undocumented anywhere, and the symbol's expected format (ticker, exchange suffix) is left entirely unspecified.

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 specific resource (quarterly sales/profit/margin/EPS) and the derived signal (year-on-year growth plus acceleration state), which is more informative than the bare tool name. It does not explicitly differentiate itself from financial_statement, which is the nearest sibling and likely overlaps.

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

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

There is no guidance on when to pick this over financial_statement or company_overview, nor on prerequisites such as whether the symbol must be a listed equity. Usage can only be inferred from the words 'quarterly' and 'trend'.

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 safety behavior is covered. The description adds useful context about the output orientation (periods × rows) and the supported statement types, but discloses nothing about the undocumented `view` mode, data freshness, or the cost of broad requests.

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 with no filler, and the output-shape statement is front-loaded ahead of the parameter notes. The 'periods × rows' phrasing is slightly cryptic for an agent unfamiliar with the response shape.

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 four-parameter, zero-schema-coverage tool with no output schema, the description covers the two most consequential parameters and hints at the return layout. It does not explain the required `symbol`, the `view` option, or what a 'row' contains, leaving real gaps an agent must guess at before calling.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it does document `statement` values (quarters | profit_loss | balance_sheet | cash_flow | ratios) even though the schema declares no enum, and it clarifies `periods` (latest N columns, 0 = all). It leaves the required `symbol` and the `view` parameter entirely undefined, so half the surface remains undocumented.

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 conveys that this returns a full financial statement in a periods-×-rows layout and enumerates the available statement types, which is informative. However, it never states the subject of the statement (a company identified by the required `symbol`) and never uses a clear verb such as 'return' or 'fetch', leaving the purpose partially inferred from the tool name.

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

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

No guidance is given about when to use this instead of siblings like company_overview, company_snapshot, or earnings_trend, all of which overlap in returning company financial context. There are no exclusions, no prerequisites, and no mention of how to choose a `statement` value for a given question.

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 useful context about the returned comparison metrics, but it does not explain peer count, data freshness, or how peers are selected.

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

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

The definition is a single front-loaded sentence with no wasted words. It presents the tool's purpose and returned metrics efficiently.

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 one parameter and no output schema, the description usefully lists returned metrics. However, it omits input semantics, peer-selection behavior, and routing guidance versus compare_companies, leaving gaps an agent must resolve from the schema.

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

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

Schema description coverage is 0%, and the description never mentions the required symbol parameter or its expected format. Although the parameter name 'symbol' is fairly self-explanatory, the description does not compensate for the missing schema documentation.

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

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

The description clearly identifies the resource as a peer comparison table and lists concrete returned metrics (price, P/E, market cap, quarterly growth, ROCE). It does not explicitly distinguish itself from the sibling compare_companies tool, 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 implies the tool is for peer comparison, but it provides no explicit when-to-use guidance, prerequisites, or alternatives such as compare_companies. An agent must infer usage from the one-sentence summary alone.

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 is read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context by stating that days snaps to specific values and that price includes 50/200-day averages and volume, but it omits other relevant traits such as data adjustment or return 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 compact sentences with no filler and is front-loaded with the metric enumeration. The pipe-separated formatting is dense, but it remains efficient and appropriately sized for the information provided.

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 three-parameter retrieval tool with no output schema, the description gives enough to invoke the tool with a metric and snapped day range, but it does not explain the symbol format or the exact returned data structure. It is minimally viable but has clear completeness gaps.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It partially compensates by listing allowed metric values and the days snapping behavior, but it does not describe the required symbol parameter or clarify defaults, leaving a clear gap.

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 says "Daily history" and enumerates metric choices, so the agent can infer it returns historical daily data for a symbol. However, it lacks an explicit verb and resource statement such as "retrieves daily price/metric history for a company," leaving the core purpose somewhat vague.

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 lists metric options and day-range snapping, but never says when to use this tool versus siblings like company_snapshot, financial_statement, or company_overview. There are no explicit inclusion or exclusion conditions for tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that the checks are fixed and evidence-backed, but it does not explain data sources, limitations, or what happens with incomplete reported numbers.

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 compact enumerated list of checks. It is dense but efficient, with little wasted text, though the list format makes it slightly run-on.

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 explains the twelve checks and says each comes with evidence, which is useful for a read-only analysis tool. However, with no output schema, it does not describe the return structure or evidence format, and it leaves the required symbol input undefined.

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

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

The schema has 0% description coverage and the description never mentions the required symbol parameter. The parameter name 'symbol' is somewhat self-explanatory, but the description adds no format, exchange, or identifier semantics to compensate for the schema gap.

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 this tool runs twelve fixed checks on reported numbers and enumerates the checks, which distinguishes it from generic financial data tools. It does not explicitly contrast itself with siblings such as company_overview or financial_statement, but the purpose is still specific and identifiable.

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 guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent can infer it is for red-flag screening, but the description does not name siblings or conditions for selecting 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 readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new operational context: a one-time Screener.in login prerequisite via the CLI, which is exactly the kind of auth requirement that would otherwise cause silent failures. It stops short of noting result-size or rate-limit 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?

Two sentences, front-loaded with the concrete query example that carries most of the informational value, and the prerequisite follows. Nothing is padded, though the login instruction could be more crisply separated from the core description.

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 say what comes back — e.g. a list of matching companies with which columns, and how 'limit' interacts with results. It also omits the sort/order semantics, leaving an agent unable to predict result shape or ordering.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does well on the required 'query' parameter by showing valid Screener.in expression syntax, but 'sort', 'order', and 'limit' (default 25) are left entirely undocumented in both schema and 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 names a specific verb and resource ('Run a Screener.in query') and supplies a concrete query example, so the agent immediately understands this is a custom fundamental screen rather than a lookup. It does not explicitly contrast with sibling screen-like tools such as theme_screen, so the differentiation is only implicit.

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 example query implies the intended use case (screening by financial ratios) and a setup prerequisite is given, but there is no explicit when-to-use versus theme_screen, nor any when-not-to-use guidance. The agent must infer that this is for ad-hoc user-authored screens.

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 fully covered. The description adds the useful detail that matching is fuzzy/partial, but stays silent on ambiguity handling, ranking of results, and what the response shape looks like — value added, but not rich context.

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

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

A single front-loaded sentence with the action, the resource, and inline examples — no filler, nothing buried.

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

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

With no output schema and no parameter descriptions, the definition should say what comes back (a list of candidate symbols?) and how ambiguous names are resolved. For a low-complexity lookup tool that omission is a real gap an agent will notice on first call.

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

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

Schema description coverage is 0%, so the description must compensate. It documents `query` well with input forms and examples, but says nothing about `limit` (default 10) or any maximum, leaving one of two parameters unexplained in both schema and 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?

Uses a specific verb ("Find") and a precise resource (a company's Screener.in symbol), plus concrete input examples ("caplin", "hdfc bank"). It clearly reads as a name-to-symbol resolution step, distinct from data-returning siblings like company_overview or financial_statement, though it never explicitly names 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?

The description implies the resolution use case and states the two accepted input forms (full/partial name, part of a ticker), but gives no explicit when-to-use guidance, no prerequisites, and no mention of what to do when multiple or zero matches come back. Usage is inferable rather than 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context by enumerating exactly what is reported (login state, quota, cool-down, cache size), which goes 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?

A single compact sentence with no filler. It front-loads the most important field (login state) and lists the rest efficiently, though the fragment lacks a verb.

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 return values, and it does list the reported fields. It stops short of defining ambiguous fields such as what 'cool-down status' or cache size actually mean, leaving some interpretive gaps.

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 there is nothing for the description to clarify; the baseline for a parameterless tool is 4.

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

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

The description names the resource (service status) and lists specific fields it reports, which separates it from the company-research siblings. However, it is a noun phrase with no verb, so the actual action (retrieve/check) is only implied rather than stated.

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

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

There is no guidance on when to call this tool, when not to, or what alternatives exist. The agent must infer usage entirely from the name and description.

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 that the data is a historical time series broken out by holder category, which is modest but real added context; it does not say how far back history goes or how many periods are returned.

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 fragments, front-loaded with the resource and holder categories; there is essentially no filler. The terseness borders on cryptic ('period: quarterly | yearly' as a standalone clause) but nothing is wasted.

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

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

The tool is simple (2 params, no output schema), but with no output schema the description should still indicate what a record contains and whether the series is returned as a list over time. As written, an agent can guess the call but not the shape of results or the depth of history.

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

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

Schema description coverage is 0%, so the description carries the burden. It supplies the two accepted values for `period` (quarterly | yearly), which the schema lacks (no enum), but says nothing about `symbol` format or about period defaulting to quarterly, leaving half the semantics to guesswork.

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 resource — shareholding history across promoter/FII/DII/government/public categories — which is clearly distinct from siblings like financial_statement or company_overview. The verb is only implied ('history'), so it stops short of a fully explicit purpose statement.

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

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

No guidance on when to use this versus company_overview, company_snapshot, or financial_statement, and no mention of prerequisites (e.g., that a valid symbol/company must exist). The agent must infer the use case entirely from the resource name.

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 the safety profile is covered. The description still adds two things the annotations don't: the authentication requirement and the discovery behavior (empty theme returns the theme listing). It omits how limit affects output or whether results are paginated.

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, front-loaded with what the tool offers before the operational notes. Minor waste in the vague 'Needs a login like run_screen' phrasing, but nothing is padded.

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 covers the essentials, but with no output schema and no explanation of limit, an agent can't predict result shape (list of theme names vs. ranked companies) or how limiting works. The auth note is a positive but somewhat ambiguous reference to a sibling.

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

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

Schema description coverage is 0%, so the description must compensate. It explains theme semantics (empty string lists available themes; plausible values are named), which is genuinely useful, but it says nothing about limit (default 25) — whether it caps companies per theme or number of themes returned.

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

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

States a specific resource — pre-built/ready-made screens — and enumerates concrete themes (quality compounders, earnings acceleration, margin expansion, turnaround), which lets an agent distinguish it from the sibling run_screen (custom screens). It never uses an explicit verb like 'run' or 'fetch', so the action is implied rather than stated.

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 one concrete usage rule — call with no theme to list available themes — plus a prerequisite ('needs a login like run_screen'). It does not explicitly say when to prefer this over run_screen for custom criteria, so the alternative-routing is only implied by the word 'ready-made'.

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