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

Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower; the description adds the genuinely important behavioral fact that output follows the Indian lakh/crore grouping rather than the Western thousands grouping. It does not disclose how fractional amounts or paise are rendered, which is the main remaining behavioral gap.

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

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

One sentence with zero filler; the core operation comes first and the disambiguating detail (Indian numbering, lakh/crore) follows immediately. Nothing is repeated from the name or title without adding 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?

The tool is simple (one numeric input, no output schema), yet the description never states what the return value looks like — a plain string, capitalization, whether "Rupees"/"Paise" is appended. For a formatting/conversion tool whose entire value is output shape, that is a meaningful omission.

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

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

Schema description coverage is 0% for the single required parameter, so the description has to compensate. Calling it a "rupee amount" does establish the unit and implicitly the currency, but it says nothing about decimal/paise handling, rounding, or the upper bound implied by the schema's minimum:0 constraint.

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 (Convert), a specific resource (a rupee amount to words), and the exact output convention (Indian numbering system with lakh/crore). The sibling list contains no other numeric-formatting tool, so the boundary is unambiguous from the description alone.

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

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

Gives concrete usage context ("as used on invoices and cheques") which tells the agent when this formatting is appropriate, and the rupee framing implicitly scopes out other currencies. It stops short of explicit exclusions or stating what to do for non-INR or non-numeric input, so it is clear but not fully prescriptive.

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, closed-world), so the bar is lower, and the description still adds real behavior: processing happens locally ('data never leaves the computer'), passwords are user-supplied and must never be guessed, bank layouts are auto-detected, every PDF row is validated against the running balance, and `include_transactions` can produce long output. Only the failure behavior for an unreadable/unparseable file is left implicit.

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 what the analysis produces, then input modes. The category list in parentheses is slightly long but earns its place by previewing the output shape. No filler sentences.

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

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

With no output schema, the description carries the burden of describing returns, and it does so by naming each report section, plus it discloses the input alternatives for a zero-required-parameter tool. The one gap is what happens if neither `file_path` nor `transactions` is supplied, which an agent would have to infer.

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 already 86%, so baseline is 3, but the description adds meaning beyond the schema: `file_path` accepts net-banking exports from named banks with automatic layout detection, `password` is specifically for protected PDFs and must come from the user, and `transactions` is the alternate path for statements the agent has read itself. `from`/`to`/`top_n` are left to the schema, which documents them adequately.

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 (analyse) and resource (Indian bank statement) and enumerates the concrete outputs: category spending, monthly in/out, top payees, largest spends, recurring payments, UPI usage. This clearly separates it from the sibling convert_bank_statement, which does conversion rather than 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?

Explains the two input modes explicitly — provide `file_path` for a PDF/CSV from net banking, or pass `transactions` directly when there is no readable file (e.g. a scanned statement). It also states the password requirement for protected PDFs. It lacks an explicit 'use this instead of convert_bank_statement when...' routing statement, but the context is clear.

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

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds genuine behavioral context beyond that: the tax split is derived from supplier state and place of supply, inclusive prices are back-calculated, cess and round-off are applied, and the total is verbalized. It does not cover failure behavior (e.g. an invalid GSTIN or unknown state) or the shape of the returned breakdown.

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

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

A single dense sentence with the core act front-loaded and the derived behaviors stacked behind it in logical order. No restatement of the title and 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?

There is no output schema, so the description carries the return-value burden and does it: the agent learns it gets a per-line tax computation with a grand total plus an amount-in-words string. Combined with the schemas for inputs, this is sufficient to call the tool 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 80%, so the baseline is 3, and the description earns one more by explaining the causal relationship the schema only states piecewise: supplier_state and place_of_supply jointly determine IGST vs CGST+SGST/UTGST, and the resulting split drives the per-item math. It does not add anything on round_off, prices_include_gst, or cess_rate beyond what the schema already says.

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 (calculate) plus resource (GST) with the exact scope spelled out: intra-state CGST+SGST/UTGST vs inter-state IGST, inclusive prices, cess, round-off, and amount in words. This clearly separates it from siblings like find_gst_rate (looks up a rate) and create_gst_invoice (produces a document).

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 capability statement implies the use case (compute a tax breakdown for line items) but never states when to prefer this tool over find_gst_rate, create_gst_invoice, or amount_in_words. No prerequisites or exclusions are given, so the agent must infer routing from capability 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 declare readOnlyHint=false with destructiveHint=false, and the description is consistent with that: it writes a CSV rather than altering the source, and 'Runs locally' corroborates openWorldHint=false, which is useful context the annotations don't state in words. It adds genuinely behavioral detail beyond the annotations - running-balance verification and that discrepancies are reported in the result. It stops short of describing error behavior or what the report looks like.

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 action and output target, then the column contract, then the correctness check and locality note - a sensible order with no filler. It is a dense, long single sentence, slightly harder to scan than it could be, but every clause carries information.

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

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

With no output schema, the description correctly takes on the burden of describing the return: per-transaction columns plus a discrepancy report from balance checking. Password and failure-debug paths live in the schema, so the main remaining gap is what the results object looks like structurally and where the CSV path is returned.

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 password, debug, file_path and output_path are already fully documented at the field level, including the default naming for output_path. The description adds no phrasing-level meaning (no format constraints on file paths, no detail on what 'reports any that don't agree' returns), 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?

Specific verb and resource: 'Convert a PDF (or CSV) bank statement into a clean CSV.' It also enumerates the output shape (one row per transaction with date, narration, reference, debit, credit, balance, plus category, payee, decoded UPI), which makes the tool unmistakably a converter rather than the sibling analyze_bank_statement. It never names that sibling, so differentiation is implied 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 implied by the input formats it accepts (PDF or CSV) and the conditional guidance in the schema ('If parsing fails...', 'Ask the user; never guess it' for passwords). There is no explicit statement of when to choose this over analyze_bank_statement or what to do with the balance-mismatch report afterwards, so the agent must infer routing.

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

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

Annotations declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, so the agent already knows this is a local, non-destructive write. The description adds real context beyond that: it states the output artifact (a PDF written to the user's computer), that it returns the file path plus the tax breakdown, and the anti-fabrication rule for missing party data. It stops short of saying what happens on file-name collision or whether an existing PDF is overwritten.

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 action and artifact, then the return value, then the guardrail. Every clause does work: scope, contents, return, and the do-not-invent rule. No filler or restatement of the title.

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 13-parameter, nested-object tool with no output schema, describing the return value is the right instinct, but 'the tax breakdown' is left vague — an agent cannot tell whether it gets a per-line CGST/SGST/IGST split or just totals. It also omits filesystem behavior such as creating a missing output_dir or handling name collisions. Adequate, but not fully sufficient for this complexity.

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

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

Schema description coverage is only 54% across 13 parameters, so the description carries some burden. It does map several parameters to document fields (place of supply, reverse charge, bank/UPI details, amount in words) and, importantly, describes return values since no output schema exists. But it adds no semantics for prices_include_gst, gst_rate/cess_rate interplay, or how ship_to differs from buyer — the highest-risk ambiguities are left to the schema alone.

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

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

The description opens with a specific verb and resource: 'Generate a GST-compliant tax invoice as a PDF on the user's computer', then enumerates the document's contents (HSN/SAC, tax split, place of supply, reverse charge, amount in words). This clearly separates it from siblings like calculate_gst, amount_in_words, or lookup_hsn_sac, which compute fragments rather than produce the finished document.

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

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

It gives one concrete operating guideline — ask the user for missing supplier or buyer details rather than inventing them — which is genuinely useful for a document-generation tool. However, it never states when to prefer this over calculate_gst or the lookup tools that supply its inputs, and offers no exclusions or prerequisites beyond that single instruction. Usage is implied rather than routed.

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

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

Annotations already declare readOnly, idempotent and closed-world, and 'Works offline' is consistent with openWorldHint=false. Beyond that, the description discloses the data currency model (all amendments applied up to the latest checked date), the exact contents of a result (rate, CGST/SGST/IGST split, notification and serial number, verbatim wording), and the multi-match caveat. It does not say what happens on a miss or how the future-dated amendment examples should be interpreted, 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?

A single dense paragraph that is front-loaded with source authority, then how to call it, then what comes back, then caveats. Almost every clause earns its place, though the parenthetical future-dated examples ('tobacco to 40% from 1 Feb 2026, psyllium exempt from 1 Nov 2026') read as noise that a reader has to decode rather than useful guidance.

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 3-parameter, no-output-schema lookup tool, the description covers source, currency, return payload and ambiguity handling well enough to call it correctly. The remaining gap is the undocumented limit cap and unstated no-match behaviour.

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 67%, so the baseline is 3. The description does add meaning for product — it searches the notifications' own wording rather than a product catalogue — and clarifies that both inputs can be combined, but it never mentions the limit parameter at all, which is the one parameter the schema leaves completely 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 states a specific verb and resource — official GST rates for goods — and names the exact source documents (Notification 09/2025 and 10/2025-Central Tax (Rate)). It also draws a hard boundary by excluding services (SAC 99xxxx), which separates it from the SAC-oriented sibling lookup_hsn_sac. It stops short of naming calculate_gst or lookup_hsn_sac as alternatives, so sibling routing is still partly inferred.

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 two concrete invocation modes: pass an HSN code for every covering entry, or pass a product description to search the notifications' own wording. It also tells the agent how to handle ambiguity — several entries can cover one code at different rates, so explain the conditions rather than silently picking one. What is missing is explicit when-not-to-use guidance, e.g. that calculate_gst should be used to compute tax on an amount.

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

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

Annotations already declare readOnly, idempotent and closed-world; the description adds genuinely non-obvious behavior beyond them — the nearest-valid-parent fallback for unknown codes and the fact that it works offline. It does not say what happens for malformed input (e.g. a 1-digit or non-numeric code), which is the one behavioral gap.

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

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

Three short sentences, zero filler, and the primary outcome is front-loaded before the fallback case and the alternative-tool pointer. Nothing redundant with the title.

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

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

With no output schema, the description correctly carries the return-value burden by naming description, chapter, heading and sub-codes, and it defines the miss case. Only the invalid/malformed-input path and any partial-match vs exact-match distinction are left 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 coverage is 100% and the single param already documents the 2-8 digit format with examples, so the description adds no syntax detail. Its added meaning is about results (fallback to parent code), not about the parameter itself, 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?

"Check whether an HSN or SAC code exists in the GST portal's official list" gives a specific verb plus resource, and the enumerated payload (description, chapter, heading, sub-codes) makes it distinguishable from search_hsn_sac and find_gst_rate without opening any 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?

Explicitly routes rate queries away: "For the GST rate, use find_gst_rate." It does not mention search_hsn_sac, which is the obvious alternative when the agent only has a partial or keyword description rather than a code, so the sibling routing is incomplete.

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, idempotentHint and openWorldHint, so the safety and repeatability profile is covered. The description adds useful context about what data comes back since there is no output schema, but it says nothing about behavior for invalid or unknown IFSC codes, lookup latency, or whether results are cached.

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

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

One sentence, zero filler, with the resource (IFSC) and the returned payload front-loaded. Every clause earns its place by telling the agent what it will receive.

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 one required parameter, no output schema, and full annotation coverage, the description is close to sufficient — it enumerates the return fields, which is the main thing the missing output schema would otherwise provide. It falls short only on failure behavior for malformed or nonexistent codes.

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

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

Schema coverage is 100%: the single `ifsc` parameter is documented with its 11-character length and an example. The description adds no format, casing, or validation detail beyond that, so the schema does all the work and the baseline of 3 applies.

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

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

The description pairs a specific verb ("Find") with a specific resource (an IFSC code) and enumerates the returned fields (bank, branch, address, MICR, payment modes), so the agent knows exactly what the tool produces. It does not explicitly contrast itself with the nearest sibling, lookup_pincode, though the resource names are distinct enough that confusion is unlikely.

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 when-to-use or when-not-to-use statement; the implication is simply that you call it when you have an IFSC. No alternatives (e.g., lookup_pincode for postal codes) or prerequisites are named, so routing is left to inference 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 readOnlyHint=true, idempotentHint=true and openWorldHint=true, so safety and repeatability are covered without description help. The description adds useful context by naming the returned fields (district, state and post offices), which partially compensates for the absence of an output schema. It does not mention lookup failure behavior for invalid PIN codes or response format details.

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 with zero filler, front-loading the resource and output fields. Every clause earns its place and nothing is redundant with the schema.

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

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

For a simple one-parameter read-only lookup, the definition covers purpose, input format and expected return fields. With no output schema, stating what is returned is valuable and largely sufficient, though error behavior for invalid PIN codes remains unspecified.

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

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

Schema coverage is 100% with a single well-described parameter ('6-digit PIN code, e.g. 110001'), so the schema carries the full burden. The description's 'Indian 6-digit PIN code' reinforces the format and country constraint, which is marginally additive but not meaningfully beyond the schema.

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

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

States a specific verb (Find) and resource (district, state, post offices for an Indian 6-digit PIN code), so the agent immediately knows the input and output shape. It does not explicitly differentiate itself from siblings, but they cover unrelated identifiers (GSTIN, HSN, IFSC), so no real ambiguity exists.

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 'Indian 6-digit PIN code' phrasing implicitly scopes the tool to Indian postal codes, which functions as light usage guidance. There is no explicit statement of when to use this versus an alternative or what prerequisites apply, but the domain is narrow enough that no reasonable alternative exists among 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 declare readOnly, idempotent and closed-world, so the description does not need to re-establish safety. It adds real value beyond them by disclosing the batch ceiling (up to 500 lines at once) and the returned fields (payee, VPA, app/bank, UTR/RRN, direction) in the absence of an output schema. What it omits is failure behavior for malformed or non-UPI narrations.

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

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

Two sentences, zero filler: the first defines the transformation and its outputs with an inline example, the second gives the capacity constraint. Both facts are front-loaded where an agent will read them.

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 one-parameter read-only parser with no output schema, the description covers input shape, output fields and batch limit, which is close to everything an agent needs to call it. The only meaningful gap is how unparseable lines are reported in 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 description coverage is 0 percent and the single parameter is an untyped-in-prose array of strings, but the description compensates: the worked example shows the expected narration format and the 500-line statement maps directly to the maxItems constraint. Format per line is conveyed by example rather than by an explicit spec, which keeps it just short of a 5.

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 (Decode) and resource (bank-statement UPI narrations), then enumerates exactly what fields are extracted (payee, VPA, app/bank, UTR/RRN reference, direction). The embedded example narration makes the input domain unmistakable and separates it from siblings like analyze_bank_statement or convert_bank_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 implies the use case clearly (bank-statement narration strings) and hints at batching via the 500-line limit, but it never states when to use this instead of analyze_bank_statement or convert_bank_statement, nor what to do with non-UPI or mixed narration lines. Usage is inferable rather than 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 cover read-only, idempotent, closed-world behavior, and the description adds useful context beyond them: 'Works offline', what the results contain (official descriptions with chapter and heading), and the advisory posture for ambiguous classifications. It does not mention result counts, ranking, or behavior when nothing matches, which would complete the picture.

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 and lookup modes, then results, then routing. Every sentence carries information, though the closing responsibility sentence is long and slightly over-explains agent conduct.

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

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

With no output schema, the description correctly describes the return shape (official descriptions plus chapter and heading) and covers both query modes and the follow-on step. The one missing element for a three-param, multi-sibling tool is explicit differentiation from lookup_hsn_sac.

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 goods/services/any enum and the 1-50 limit. The description's inline examples ('laptop', 'ghee', 'CA services') illustrate query phrasing but largely restate what the schema already says, 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?

Specific verb and resource: it finds HSN (goods) or SAC (services) codes from the official GST master list, and states both lookup modes (description or code prefix). It is clear on its own, but it never distinguishes itself from the sibling tool named 'lookup_hsn_sac', which an agent could easily confuse with this one.

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 explicit routing to find_gst_rate ('for the GST rate of goods, pass the code to find_gst_rate') and clear operating guidance to show candidates and defer to the user/CA on classification. The gap is that the closest alternative, lookup_hsn_sac, is never mentioned, so the when-to-use-this-vs-that condition is incomplete.

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 description discloses critical behavioral traits beyond the annotations, specifically that the tool 'works offline.' This operational constraint is highly valuable context for an agent planning its execution environment.

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 highly concise, using only two sentences to cover the function, the scope of the checks, and the operational constraints. The information is front-loaded and structured logically.

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

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

Given that the tool is relatively simple (one parameter) and highly constrained by its offline nature, the description is exceptionally complete. It covers functionality, scope, and limitations without requiring the agent to infer 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?

While the input schema is very clear (100% coverage), the description adds crucial semantic context by specifying that the input must be an 'Indian GSTIN' and defining what types of checks are performed (format, state code, and checksum). This clarifies the domain scope of the tool.

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

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

The description explicitly states the tool's purpose: to 'Check whether an Indian GSTIN is valid' and 'decode its state, PAN and entity type.' This is a clear and specific function that immediately differentiates it from other lookup or calculation tools in the sibling list.

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

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

The description provides a vital usage limitation, stating that while it validates the format, it 'does not confirm the registration is active on the GST portal.' This gives the agent a clear boundary for when the tool's output should be trusted.

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