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

Annotations already establish read-only, idempotent, closed-world behavior, yet the description adds genuinely new context: dates are standard statutory dates, government extensions are excluded, and each entry comes with legal basis and official authority. That tells the agent how much to trust the output before it calls. It does not discuss output ordering or completeness limits, so it is not exhaustive.

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?

Four sentences, front-loaded with purpose, followed by defaults, parameter nuance, and the accuracy caveat. The defaults and state sentences overlap with what the schema already states, so some content is duplicated rather than 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?

There is no output schema, and the description compensates by stating what each date carries (legal basis, official authority) and, crucially, the limitation that extension dates are missing. For a four-parameter, zero-required read-only lookup this is close to complete; a hint on the shape or count of returned entries would close the remaining gap.

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

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

Schema description coverage is 100%, so all four parameters are already documented, including that `state` drives the QRMP GSTR-3B date and that `from`/`to` default to today in IST and 30 days later. The description restates those defaults rather than adding new meaning, so baseline 3 applies.

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

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

The description opens with a specific verb and resource ("Lists standard Indian compliance due dates"), enumerates the covered categories (GST, TDS, advance tax, EPF/ESI, ROC), and scopes the result to a date range. It is unmistakably distinct from the sibling tools, which are all single-value validators or holiday/pincode lookups.

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 clear operating context: defaults to the next 31 days in IST, pass a state only when QRMP GSTR-3B applies, and a warning that extensions are excluded so dates must be confirmed against the official notification. It stops short of naming alternatives (e.g. pointing to india_holidays for public holidays or state_info for registration details), which keeps it from a 5.

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

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

Beyond the annotations, it discloses the authoritative source (DoPT order), supported years (2026 and 2027), coverage limits (no state, bank, or stock-exchange holidays), and a key accuracy caveat that moon-dependent festival dates may shift by a day.

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 tightly written sentences, front-loaded with purpose and followed by exclusions and caveats. Every clause earns its place.

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

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

For a simple two-parameter read-only lookup with no output schema, the description gives enough context to call it correctly, understand its coverage, and interpret its limitations. Nothing material is missing.

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

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

Schema description coverage is 100%, so baseline is 3, but the description adds meaningful semantics: `date` triggers a check rather than a list, and when both parameters are given, `date` takes precedence. It does not add format details beyond what the schema already states.

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

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

The description states a specific verb and resource: it lists Central Government closed (gazetted) holidays for a year or checks whether a given date is one. It clearly scopes the dataset to DoPT orders and 2026-2027, and distinguishes this from broader holiday categories.

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 explicitly explains the two usage modes: list by year or check a date, and states precedence when both are supplied (`date` is used). It also names what is excluded, which prevents misuse for state, bank, or stock-exchange holidays.

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=false. The description adds meaningful context beyond that: it identifies the bundled India Post directory and warns that dated data means newer pincodes will not be found. It does not describe error behavior for malformed input, but the key data-source limitation is disclosed.

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

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

The description is two sentences, front-loaded with what is returned and followed by the important staleness caveat. Every sentence earns its place with no unnecessary wording.

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

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

For a simple one-parameter read tool with no output schema, the description enumerates the returned fields and explains the source and date limitation. It is nearly complete, though it could explicitly state what happens for an invalid or not-found pincode.

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

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

Schema description coverage is 100%, and the schema already documents the single pincode parameter as a 6-digit value. The description repeats the 6-digit requirement but adds no additional syntax or format meaning beyond what the schema provides, so this is the baseline score.

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

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

The description states a specific verb and resource: it returns state, district, postal circle, and post offices for a 6-digit Indian pincode. This clearly distinguishes it from sibling validators such as validate_gstin and validate_pan, which check formats rather than look up directory data.

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

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

The description gives a clear lookup context and adds a useful staleness caveat about pincodes created after the directory date. However, it does not explicitly name alternatives or state when not to use this tool versus sibling tools like state_info.

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

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

Annotations already establish readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful behavior that annotations cannot convey: the exact return payload (GST code, RTO prefixes, capital, QRMP GSTR-3B due day group) and the 'no query returns all 36' default. It stops short of saying how an unmatched query is handled or whether the result is a single record or a list when a partial name matches several states.

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

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

Two sentences with no filler: accepted inputs first, returned fields second, the list-all default front-loaded at the end where it is immediately actionable. Examples are embedded inline rather than given their own clauses.

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

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

A one-parameter, optional-parameter lookup with full schema coverage has modest requirements, and the description fills them by naming the returned fields in lieu of an output schema and stating the empty-query behavior. Nothing an agent needs in order to call it correctly appears to be absent.

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

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

Schema coverage is 100%, and the schema's own description already says 'A name, GST code, ISO code or RTO prefix. Leave out to list all.' The prose restates that almost verbatim with illustrative values, adding only marginal meaning beyond the structured field, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource ('Looks up an Indian state or union territory') and enumerates the four accepted identifier types with concrete examples (27, IN-MH, MH). It is clearly a static reference lookup, which distinguishes it from the sibling tools, all of which validate or compute against inputs rather than resolve a code.

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 clear invocation contexts: supply any of four identifier forms, or omit the query to enumerate all 36. What is missing is any exclusion or error guidance, such as what happens on a misspelled name or an out-of-range code, and it does not explicitly redirect to a sibling for adjacent needs.

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

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

Annotations already declare readOnly, idempotent and closed-world, but the description goes well past them: nothing is stored, logged or looked up, and only the last 4 digits come back. That is exactly the privacy-relevant behavior an agent needs to know before sending a sensitive identifier, and it is information the annotations could not convey.

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

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

Three short sentences, each doing distinct work: what is checked, what is not done with the input, and what the result does and does not prove. The scope restriction is front-loaded, 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 single-parameter, no-output-schema validator, the description covers the input rules, the privacy behavior, and the return shape (last 4 digits plus a pass/fail semantics). Nothing an agent needs in order to call it correctly or interpret the answer is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning about what the parameter must contain (12 digits subject to a starting-digit rule and a Verhoeff checksum), while the schema supplies the 'spaces allowed' detail and length bounds; the two are complementary rather than redundant.

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 ('Checks only the FORMAT of an Aadhaar number') and enumerates the exact rules applied: 12 digits, not starting with 0 or 1, Verhoeff checksum. The word 'only' immediately separates it from any sibling that might look up or verify real numbers, so an agent can distinguish it from validate_gstin/validate_pan/lookup_pincode 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?

It gives explicit negative guidance ('Do not use this to identify people') and a critical caveat that a pass does not mean the number was issued, which defines the boundary of what the result means. What it lacks is a positive framing of when to reach for this versus the other validate_* siblings, though the resource named in the description makes the split fairly obvious.

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

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

Annotations only declare readOnly/idempotent/closed-world; the description adds genuinely new behavior: validation is done offline with no registry lookup, and a pass means only well-formed, 'not registered or active.' That last caveat is exactly the kind of interpretive guardrail an agent needs when acting on the result.

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?

Four tight sentences, front-loaded with what is checked, then motivation, then format limits, then the result caveat. No filler and no repetition of the name or 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 must carry the return contract, and 'Returns the decoded parts' is only a sketch — an agent does not know which fields come back or what a failure looks like. Everything else an agent needs (scope, exclusions, meaning of success) is present.

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?

Only one parameter and the schema already documents it at 100% coverage, including that spaces or hyphens are accepted. The description adds no input-format detail (e.g. case normalization or the 40-char max), 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?

Names a specific verb and resource ('Checks an Indian GSTIN') and enumerates exactly what is verified: 15-character structure, state code, embedded PAN, and mod-36 check character. The offline scope plus the stated format boundary (regular-taxpayer, 14th char Z) cleanly separates it from validate_pan and the other validate_* 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?

Gives an explicit use case ('use this instead of guessing whether a GSTIN is well-formed; a model cannot calculate the check character reliably') and explicit exclusions (TDS/TCS, UN-body, non-resident formats unsupported). It falls short of 5 because it never names where the agent should go for the excluded formats, so alternatives remain unstated.

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 behavior, so the safety profile is covered. The description adds real value beyond that by disclosing that bank names are resolved only for well-known codes (partial coverage) and by stating the negative capabilities. It does not say what happens on a malformed input (error vs. a failed-validation result), which is a meaningful gap for a validator.

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

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

Two tight sentences: the positive capability with its rule comes first, the limitation second. No filler, no repetition of the title, 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?

For a single-parameter, no-output-schema validation tool, the description covers what is checked, what extra data (bank name) may come back, and the limits of the result. The only omission is the shape of an invalid-format response, which matters somewhat since no output schema exists.

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 parameter is documented, so the baseline is 3. The description does add structural meaning beyond the schema by decomposing the code into 4 letters + zero + 6 branch characters, though it leaves a slight inconsistency with the schema's maxLength of 30 versus the stated 11 characters unaddressed.

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 ('Checks the format') and resource (IFSC code) and spells out the validation rule (4 bank letters, a zero, 6 branch characters), so an agent knows exactly what is examined. The IFSC resource is inherently distinct from the sibling validators (GSTIN, PAN, Aadhaar), though no sibling is named 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?

Clear scope boundaries are given: it validates format only and explicitly does NOT confirm branch existence or return an address, which steers an agent away from using it as a branch lookup. It stops short of naming an alternative tool to use instead when branch or address data is needed.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds behavior beyond that: the check is performed offline and a pass has bounded meaning (no issuance, no ownership attestation), which prevents over-trusting the result. What's missing is the shape of the return value (boolean vs. structured result), so it falls 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?

Two sentences, no filler. The positive capability is stated first and the limitation ('a pass does not prove...') is front-loaded as a caveat in the second sentence. 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?

For a single-parameter, read-only, no-output-schema validator this is nearly sufficient: the rules checked and the limits of a pass are both covered. The only gap is that it doesn't indicate the response shape — e.g., whether it returns only a boolean or also the decoded holder type — which matters since no output schema exists.

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 there is only one parameter, so baseline is 3. The description earns above baseline by adding real meaning to the input: the exact 10-character structure and the fact that character 4 encodes holder type, which the schema's 'The 10-character PAN' does not convey.

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 gives a specific verb and resource: 'Checks an Indian PAN offline', and then enumerates exactly which rules are checked — the 5-letter/4-digit/1-letter shape and the holder-type character in position 4. This is enough to tell it apart from siblings like validate_gstin or validate_aadhaar_format 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?

Usage context is clear: it is an offline format validator, not an issuance or ownership check, and the description states that a pass does not prove the PAN was issued or who owns it. It doesn't explicitly contrast with a hypothetical online lookup or name alternatives, but with a sibling set of distinct per-identifier validators the selection is unambiguous.

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