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

With no annotations, the description carries the full burden and does disclose the default-filling precedence: defaults come from scripcode and quarter, and anything in params overrides them. That is genuinely useful behavior. However it omits error behavior for invalid endpoints, auth requirements, rate limiting, and response size/pagination characteristics for a raw passthrough.

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?

Single paragraph, front-loaded with purpose and return format, then the necessary endpoint enumeration, then the defaulting rule. The long endpoint list is bulky but is the only place that enum exists, so every token 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 states the return type (raw decoded JSON), which substitutes for the missing output schema, and covers the parameter-defaulting model. For a generic gateway spanning 23 endpoints with no schema descriptions, no annotations, and no per-endpoint parameter documentation, an agent still lacks error handling and per-endpoint argument guidance.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it supplies the full enum of endpoint values (absent from the schema), documents the quarter format ('130.00' or 'Q1 FY27'), and explains how scripcode/quarter feed defaults while params overrides them. It stops short of describing per-endpoint params shapes, but the override rule is unambiguous.

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 ('Call any documented BSE endpoint and return its raw decoded JSON') and enumerates the 23 valid endpoints, which makes the scope concrete. It does not explicitly contrast itself with the curated siblings (get_quote, get_market_depth), so an agent must infer that this is the generic escape hatch.

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 statement of when to use this low-level passthrough versus the specialized sibling tools it overlaps with (e.g. the MarketDepth endpoint vs get_market_depth, GetQuoteAllSearchDatabeta vs get_quote). The endpoint enumeration implies usage but gives no selection rule or prerequisites.

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

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

With no annotations, the description carries the full burden, but it does disclose the key traits: this writes a file to disk (a mutation side effect) and returns the file path. However, it omits important behaviors such as whether an existing filename is overwritten, whether save_dir must already exist, and how download errors surface.

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 sentence that front-loads the action, names the destination parameter, marks filename as optional, and states the return value. Every clause earns its place with 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?

An output schema exists, so return-value detail is not strictly required (the description still confirms the file path is returned). For a write-to-disk tool with no annotations, the description covers source, destination, naming, and return, leaving only edge-case behaviors like overwrite/error handling unstated.

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

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

Schema description coverage is 0%, so the description must compensate, and it does explain all three parameters: attachment (source object from get_announcements), save_dir (destination), and filename (optional override). It adds real meaning over the bare schema, though it doesn't specify path/filename format expectations.

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 ('Save') and resource ('an announcement's PDF') and explicitly identifies the input's provenance as the 'attachment' from get_announcements, which distinguishes it from read-only siblings like get_announcements and get_quote. An agent can tell exactly what this tool does without opening the schema.

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

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

The parenthetical 'the attachment from get_announcements' effectively tells the agent when this tool applies and how to chain it after get_announcements. It provides clear context but no explicit exclusions or named alternative (e.g., what to do for non-PDF attachments).

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

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

With no annotations, the description carries the full behavioral burden. It discloses newest-first ordering, the 1–12 month limit and BSE's behavior beyond that, category values, pagination size, and total count, though it omits auth, rate limits, and 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?

A single compact paragraph front-loads the purpose, then moves through parameter constraints without filler. Every sentence adds 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?

For a tool with no annotations and no output schema, the description gives purpose, key parameter semantics, pagination behavior, and a notable limitation. It still leaves scripcode format and fuller return structure unexplained.

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 months, category, and page clearly, but leaves the required scripcode format implicit and references a 'total' that is not a 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?

States a specific verb/resource (corporate announcements and filings for a BSE scrip), plus ordering and PDF-link details that help separate it from quote or financials siblings. It does not explicitly name an alternative 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 provides parameter constraints but no when-to-use guidance, no exclusions, and no named alternatives. Usage is only implied by the tool's purpose.

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

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

With no annotations, the description carries the full burden and does well: it discloses ordering (newest first), that values are as originally filed, the sign convention (expenses negative), and the unit caveat (Rs million for most companies). It omits auth/rate-limit and error behavior, keeping it short of a 5.

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

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

Front-loaded with purpose, then parameter meaning, then data caveats. Every clause carries information an agent needs (range, format, defaults, sign convention, units) with 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 or annotations, the description covers what is returned, ordering, units, sign conventions, and both optional-parameter defaults, which is nearly sufficient for a 3-param read tool. The unexplained required scripcode keeps it from being 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 0%, so the description must compensate. It documents 'quarters' with a 1-16 range, 'upto' with a concrete format example ('Q1 FY27') and its default detection behavior, but the required 'scripcode' parameter is never explained, leaving a meaningful 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?

States a specific resource (quarterly P&L from BSE results filings) plus derived metrics (EBITDA, margins, tax rate) and ordering (newest first). This is clearly distinguishable from siblings like get_quote, get_peers, or get_announcements, which cover 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?

Usage is implied by the content (fetch historical quarterly financials for a scrip) and the default 'upto' behavior is explained, but the description never says when to prefer this over alternatives or names any sibling. No exclusions or prerequisites are given.

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

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

With no annotations, the description carries the full burden. It usefully discloses the returned payload shape (top-5 levels with price, quantity, and totals), which is valuable since there is no output schema. It says nothing about data freshness, exchange hours, rate limits, or permissions, so behavioral coverage is partial.

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 sentence, front-loaded with the resource (market depth), then its content, then its scope. Every clause carries information 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?

For a low-complexity single-parameter read tool with no output schema, the description adequately conveys what comes back (top-5 bid/ask levels with totals). It omits the scripcode format and any freshness/authorization context, which are the remaining gaps an agent would need.

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?

One required parameter with 0% schema description coverage, so the description must compensate. Saying 'for one BSE scrip' confirms the parameter identifies a single scrip but does not specify the expected format (numeric scrip code vs. symbol), leaving a real 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?

States a specific resource and scope: top-5 bids and asks with price/quantity/totals for one BSE scrip. This is clearly distinct from siblings like get_quote, get_peers, or get_financials, though it never names the distinction explicitly. An agent can identify the resource, just not formally rule out alternatives from the text 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?

No when-to-use guidance and no mention of alternatives. The description does not say when market depth is preferred over get_quote (e.g. when the order book rather than the last traded price is needed). Usage is only implied by 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states the data source (BSE) and returned metrics, but omits read-only confirmation, authentication requirements, rate limits, and data freshness or pagination 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 definition is a single front-loaded sentence that leads with the tool's purpose. However, the long enumeration of return fields is largely redundant because an output schema already exists, adding length without proportional value.

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 read tool with an output schema, the description covers the core purpose and data source. It still leaves the parameter format undocumented and gives no guidance on when to choose this tool over siblings like get_financials.

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% for the single required parameter. The phrase 'for a scrip' loosely connects to 'scripcode', but no format, syntax, or example is given, so the description does little to 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 states a clear resource ('BSE's peer group for a scrip') and enumerates the exact fields returned, which distinguishes it from general quote or financials tools. It does not explicitly name sibling alternatives, so it stops short of a 5.

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

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

The description only says what the tool returns; it gives no when-to-use condition, no when-not-to-use exclusions, and no alternative sibling tools to consider. Usage is implied at best, with no explicit 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?

No annotations exist, so the description carries the full burden. 'Live' does disclose data freshness, but nothing is said about auth requirements, rate limits, or behavior on an invalid/missing scripcode. For a simple read tool this is acceptable but thin.

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 contents are front-loaded in one dense but informative sentence, followed by a single compact parameter note. No filler, 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 and no annotations, the field enumeration is what makes the tool callable and interpretable. The only gap is the absence of usage routing against the many sibling lookup 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 description coverage is 0% — the property 'scripcode' has no description — but the description compensates by defining it as 'the 5-6 digit BSE code', supplying both the identity and the expected 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 resource and scope: 'Live price and key facts for one BSE scrip', then enumerates the exact data points (LTP, change, ranges, valuation ratios, flags). This clearly separates it from get_financials and get_market_depth, though it never names a sibling explicitly.

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

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

There is no when-to-use, when-not-to-use, or alternative routing. The phrase 'for one BSE scrip' only faintly implies a single-scrip lookup versus list_scrips/search_scrips; an agent gets no signal on choosing this over get_market_depth or get_financials.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the return shape (up to `limit` rows plus a total count) and a performance/size caveat about BSE's side. It stops short of stating read-only nature, auth requirements, rate limits, or error behavior, so it is strong but not complete.

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-loads what the tool lists, then filters, then the performance caveat. The long segment enumeration is dense but earns its place given the total absence of enums in the schema, though the single sentence is somewhat overloaded.

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 six-parameter, zero-annotation, no-output-schema tool, the description covers filters, return shape, and the size pitfall. The remaining gap is sibling disambiguation (search_scrips) and any mention of permissions or failure modes, which keeps it from being 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 description coverage is 0% and the schema only exposes bare titles plus defaults, so the description has to compensate — and it does, enumerating accepted segment values, status values (Active/Suspended/Delisted/''), group code examples, and mapping scripcode to 'one exact code' versus name_contains to 'a name fragment'. Every one of the six parameters gains meaning the schema does not provide.

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 (List) and resource (BSE securities from the List of Securities page) plus the filter dimensions. It is precise about what is returned, but never distinguishes itself from the sibling search_scrips, which an agent would reasonably confuse it with.

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 real usage condition — add a filter because unfiltered big segments return several MB — which is genuinely actionable. However, it offers no guidance on when to choose this over search_scrips or the other lookup siblings, leaving the main selection decision implicit.

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

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

With no annotations, the description carries the full burden, and it does disclose a result cap ('up to 20 matches') and the returned fields. It omits other behavioral traits such as pagination, matching behavior, empty-result handling, and any auth/rate constraints, so the disclosure is partial.

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: what it finds, what it accepts, what it returns, and the follow-on tip. Every sentence earns its place and the purpose is front-loaded.

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

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

An output schema exists, so the return-field list is redundant but harmless; the description adds the result cap and the 'use the scripcode elsewhere' workflow cue. Nothing essential is missing for a single-parameter lookup 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 0% — the 'query' property has no description at all — so the description must compensate, and it does: it names the four accepted identifier forms and gives three worked examples ('reliance', 'ABB', 'INE117A01022'). It does not clarify matching rules (partial vs exact) for the 'code fragment' case.

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 ('Find BSE scrip codes') and enumerates the accepted identifier types (company name, symbol, ISIN, code fragment) with concrete examples. This implicitly separates it from the sibling list_scrips, but it never names that sibling or draws the contrast 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?

'Use the scripcode in the other tools' tells the agent this is a lookup starting point and signals downstream workflow, which is useful. However, it gives no guidance on when to prefer this over list_scrips, nor any precondition or exclusion, leaving the search-vs-enumerate choice to inference.

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