Prepare Indian GST refund records, validate entries and generate Statement 3 and Annexure B JSON.
Scored across 11 tools
Each tool targets a distinct action or resource, with clear parallel tools for Statement 3 and Annexure B (validate, generate, get requirements). The remaining tools (check_receipt_allocation, explain_upload_error, get_refund_checklist, search_refund_guides, read_refund_guide) have non-overlapping purposes. No two tools appear to do the same thing.
All tool names use snake_case with a consistent verb_noun pattern (e.g., validate_statement3, generate_annexure_b, get_refund_checklist). The parallel naming for Statement 3 and Annexure B tools reinforces predictability. No mixing of conventions.
With 11 tools, the set is well-scoped for the domain of GST refund preparation and validation. Each tool earns its place, covering the two main forms (Statement 3 and Annexure B) and supporting activities. The count is neither excessive nor thin.
The tools cover the full lifecycle for both Statement 3 and Annexure B: learning required fields, validating data, generating files, and explaining upload errors. Additional tools for checklists, guides, and receipt allocation checks round out the surface without obvious gaps.
Checks how bank receipts are allocated to export invoices: arithmetic, duplicate allocations, missing row references, overallocated receipts and invoice balances. Takes anonymous row numbers and integer INR paise only; names, GSTINs and certificate numbers are not needed. Up to 200 invoices, 200 receipts and 1000 allocations.
| Name | Required | Description | Default |
|---|---|---|---|
| invoices | Yes | ||
| receipts | Yes | ||
| allocations | Yes |
| Name | Required | Description |
|---|---|---|
| unit | No | |
| issues | Yes | |
| sources | No | |
| summary | No | |
| currency | No | |
| nextStep | No | |
| arithmeticValid | Yes | |
| invoiceBalances | Yes | |
| receiptBalances | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value beyond that: the input constraints (anonymous row numbers, integer INR paise, no names/GSTINs/certificates) and hard caps (200 invoices, 200 receipts, 1000 allocations), which tell the agent how to prepare input and what limits exist.
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 dense sentences, both front-loaded: the first lists what is checked, the second lists input form and limits. Every clause conveys distinct, necessary information 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 values need not be explained. The description covers what is checked, input requirements (anonymous rows, paise) and size limits, which is sufficient for a three-array validation tool. Only the explicit linkage rule (invoiceRow/receiptRow must reference valid row indices) is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the semantics, and it does useful work: it specifies amounts are integer INR paise and that rows are anonymous reference numbers. This clarifies the unit and cross-referencing meaning behind row/invoiceRow/receiptRow/amountPaise that the bare schema does not, though it does not map each array field individually.
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 (Checks) and resource (how bank receipts are allocated to export invoices), then enumerates the exact conditions checked: arithmetic, duplicate allocations, missing row references, overallocated receipts, invoice balances. This clearly separates it from the sibling validate_* and get_*_requirements tools, which operate on annexures/statements/refunds rather than receipt-invoice allocation.
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 usage (you have invoice, receipt and allocation rows to reconcile) and gives a precondition — that anonymous row numbers and integer INR paise suffice, names/GSTINs/certificate numbers are not needed. However, it never states when to use this versus a sibling tool or any exclusion, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the documented checks and correction steps for one known problem with a Statement 3 or Annexure B file. Statement 3 issues: json_generation, receipt_allocation, corrected_retry, return_mismatch. Annexure B issues: duplicate_document, gstr2b_mismatch, reversals, json_generation.
| Name | Required | Description | Default |
|---|---|---|---|
| issue | Yes | ||
| document | Yes |
| Name | Required | Description |
|---|---|---|
| issue | Yes | |
| title | Yes | |
| checks | Yes | |
| sources | No | |
| document | Yes | |
| nextStep | Yes | |
| sourcesChecked | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds that it returns 'documented checks and correction steps' for a single named problem, which is useful framing, but it does not describe output depth, lookup behavior for unknown issues, or failure modes.
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 tight sentences with the general behavior front-loaded and the valid issue values grouped by document. Zero 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 structure need not be explained, and the annotations cover the safety profile. The only remaining need is the when-to-use routing versus sibling tools, which is 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 description coverage is 0%, and the flat enum lists do not document the cross-parameter constraint. The description compensates by mapping issues to documents (receipt_allocation, corrected_retry, return_mismatch on Statement 3; duplicate_document, gstr2b_mismatch, reversals on Annexure B; json_generation on both), which is real semantic value 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 ('Returns the documented checks and correction steps') plus the resource (a known problem with a Statement 3 or Annexure B file) and scope ('one known problem'). This clearly separates it from siblings like validate_statement3 and generate_annexure_b, which act on files rather than explaining issues.
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 (call it when you already know which issue you are dealing with, to get checks and correction steps), but the description never says when to prefer this over get_statement3_requirements or validate_statement3. No explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates the Annexure B JSON (statement of inward-supply invoices) for a GST refund of accumulated ITC (RFD-01), the file the GST portal otherwise requires from its Excel offline utility, from records that pass validate_annexure_b. Returns openUrl, a link the user opens in a browser to sign in by email, pay once per GSTIN and refund period, and download; the checked records are stored behind the link for 24 hours. With a connected account that has paid, it returns the file. The tool takes no GST portal password or OTP. ITC eligibility, reversal amounts and GSTR-2B periods come from the taxpayer's reviewed records; the tool does not infer them.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The document's fields, as its requirements tool lists them, or a JSON file from the official utility unchanged. | |
| link | No | The openUrl from the other generate tool's result, so that one link holds both files. | |
| direct | No | true to have the file returned to this client. It needs the user's Fast GST Refund account to be connected; if it is not, the client is asked to sign in. Leave out unless the user asked for the file here. |
| Name | Required | Description |
|---|---|---|
| file | No | |
| claim | No | |
| valid | Yes | |
| errors | No | |
| status | Yes | |
| message | No | |
| openUrl | No | |
| summary | No | |
| document | Yes | |
| linkNote | No | |
| nextStep | No | |
| warnings | No | |
| documents | No | |
| expiresAt | No | |
| linkStatus | No | |
| inputFormat | No | |
| jsonVersion | No | |
| utilityVersion | No | |
| generatorVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the full interaction model: the returned openUrl, browser email sign-in, payment once per GSTIN and refund period, 24-hour storage of checked records, direct-return behavior for connected paid accounts, and the absence of any GST portal password/OTP. It also states the tool does not infer ITC eligibility, reversal amounts, or GSTR-2B periods.
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 the core purpose in the first clause and keeps to three information-dense sentences, but the middle sentence packs several distinct behaviors (sign-in, payment, expiration, download) into one long construction at some cost to scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, yet the description still clarifies what the link yields and how long it lives. For a multi-step, payment-gated generation tool, nothing an agent needs to call it correctly 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 the schema already documents data, link, and direct. The description adds only marginal parameter-level meaning (the connected-account behavior behind direct), which does not exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — creating the Annexure B JSON (inward-supply invoice statement) for an RFD-01 GST refund — with the domain context that distinguishes it from siblings. It also names validate_annexure_b as the gate for input records, so an agent can separate generation from validation without reading either 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?
Implies the prerequisite that records must pass validate_annexure_b, and gives explicit guidance on the direct flag ('Leave out unless the user asked for the file here'). It does not, however, state when generation is not appropriate or point to alternatives like get_annexure_b_requirements for field discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates the Statement 3 JSON for a GST refund of accumulated ITC on exports without payment of tax (RFD-01), the file the GST portal otherwise requires from its Excel offline utility, from records that pass validate_statement3. Returns openUrl, a link the user opens in a browser to sign in by email, pay once per GSTIN and refund period, and download; the checked records are stored behind the link for 24 hours. With a connected account that has paid, it returns the file. The tool takes no GST portal password or OTP.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The document's fields, as its requirements tool lists them, or a JSON file from the official utility unchanged. | |
| link | No | The openUrl from the other generate tool's result, so that one link holds both files. | |
| direct | No | true to have the file returned to this client. It needs the user's Fast GST Refund account to be connected; if it is not, the client is asked to sign in. Leave out unless the user asked for the file here. |
| Name | Required | Description |
|---|---|---|
| file | No | |
| claim | No | |
| valid | Yes | |
| errors | No | |
| status | Yes | |
| message | No | |
| openUrl | No | |
| summary | No | |
| document | Yes | |
| linkNote | No | |
| nextStep | No | |
| warnings | No | |
| documents | No | |
| expiresAt | No | |
| linkStatus | No | |
| inputFormat | No | |
| jsonVersion | No | |
| utilityVersion | No | |
| generatorVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write/not-read-only, closed-world, non-idempotent, and destructive; the description adds genuinely new context: an email sign-in, a per-GSTIN/per-period payment, a 24-hour storage window behind the link, and that no GST portal password or OTP is taken. It never explains why destructiveHint=true applies to a file-generation tool, 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?
Front-loads the artifact and its purpose, then layers return behavior, payment/expiry semantics, and the auth constraint in a tight, waste-free sequence. Every clause carries information the agent cannot get from structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description needn't enumerate return fields, yet it still explains openUrl's role, expiry, and payment model, plus the annotation-covered safety profile. It is close to complete, with only the destructive flag left unaddressed.
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 all three parameters are documented there, including the 300-char limit on 'link' and the sign-in consequence of 'direct'. The description references the openUrl return rather than adding syntax or constraints beyond the schema, so the baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (creates the Statement 3 JSON for GST refund RFD-01) and grounds it against the sibling pipeline by noting the records must pass validate_statement3. An agent can distinguish this from validate_statement3, get_statement3_requirements, and the annexure tools without opening a 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 prerequisite is explicit ('from records that pass validate_statement3'), and the 'direct' behavior is tied to a stated condition (connected, paid account). It does not name the requirements sibling or say when to prefer link-based delivery over direct, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the fields of the Annexure B JSON (statement of inward-supply invoices) for a GST refund of accumulated ITC (RFD-01), the file the GST portal otherwise requires from its Excel offline utility, and where each value comes from: purchase documents, tax amounts, the GSTR-2B period, reviewed ITC eligibility and the eight GSTR-3B reversal totals, with the fields each supply type leaves empty. Takes no input. Use it before validate_annexure_b to learn which fields to collect.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| scope | No | |
| checks | No | |
| limits | No | |
| sha256 | No | |
| sources | Yes | |
| utility | No | |
| accepted | No | |
| document | Yes | |
| workflow | Yes | |
| references | No | |
| inputSchema | Yes | |
| jsonVersion | No | |
| notIncluded | No | |
| utilityVersion | No | |
| generatorVersion | No | |
| fieldRulesBySupplyType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the source of each value (purchase documents, tax amounts, GSTR-2B period, reviewed ITC eligibility, eight GSTR-3B reversal totals) and the fact that certain fields are left empty per supply type.
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 resource identity, followed by value-origin detail and then the routing instruction. The middle sentence is dense and long, but every clause carries substantive information about the returned fields rather than 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 values need not be enumerated in prose; the description instead adds domain framing and workflow ordering, which is exactly the right complement. It is complete enough to call the tool correctly, though the pre-validation step could have named its other sibling (generate_annexure_b) for full routing coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description's explicit 'Takes no input' correctly reinforces the empty 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?
Names a specific verb and resource ('Returns the fields of the Annexure B JSON') and pins down the domain context (inward-supply statement for an RFD-01 ITC refund). It is clearly distinguishable from the sibling generate_annexure_b and validate_annexure_b tools, which produce and check the same artifact.
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 the agent: 'Use it before validate_annexure_b to learn which fields to collect.' It also states 'Takes no input', removing any ambiguity about invocation. Both when-to-use and its relative ordering in the workflow are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the records to gather, the checks to make, the next step and the relevant guides for one stage of a service-export GST refund claim and one preparation topic. Use it when someone asks what to prepare or check.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| stage | Yes |
| Name | Required | Description |
|---|---|---|
| need | Yes | |
| scope | No | |
| stage | Yes | |
| title | Yes | |
| checks | Yes | |
| guides | No | |
| records | Yes | |
| summary | Yes | |
| nextStep | Yes | |
| needLabel | No | |
| stageLabel | No | |
| createFiles | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, covering the safety profile. The description adds that the output includes records, checks, next step, and guides, which enriches understanding of the return content beyond annotations – though the output schema may already document this, so the added value is moderate.
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 what is returned, followed by when to use it. No redundant or wasted text.
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 the tool has a clear output schema, annotations that cover safety, and enum parameters that are self-explanatory, the description provides adequate context. It could be improved by differentiating from siblings, but it is largely complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but both parameters are enums with fully listed values in the schema itself. The description mentions 'one stage' and 'one preparation topic,' mapping to stage and need, but adds no semantic detail about the enum meanings. Baseline 3 is appropriate since the enums are self-documenting.
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 the records to gather, the checks to make, the next step and the relevant guides' for a refund preparation checklist. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like read_refund_guide or get_statement3_requirements, aside from the checklist framing.
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 says to use it 'when someone asks what to prepare or check,' which gives clear context. However, it does not name alternatives or state when not to use it, stopping short of the explicit alternative routing seen in top-scoring definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the fields of the Statement 3 JSON for a GST refund of accumulated ITC on exports without payment of tax (RFD-01), the file the GST portal otherwise requires from its Excel offline utility, and where each value comes from: export invoices and notes, bank BRC/FIRC rows, and shipping details for goods. Takes no input. Use it before validate_statement3 to learn which fields to collect.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| scope | No | |
| checks | No | |
| limits | No | |
| sha256 | No | |
| sources | Yes | |
| utility | No | |
| accepted | No | |
| document | Yes | |
| workflow | Yes | |
| references | No | |
| inputSchema | Yes | |
| jsonVersion | No | |
| notIncluded | No | |
| utilityVersion | No | |
| generatorVersion | No | |
| fieldRulesBySupplyType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful context beyond them: that it takes no input and, importantly, the provenance of each field (export invoices/notes, bank BRC/FIRC rows, shipping details), which shapes what the agent can expect to collect.
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 purpose, followed by the data-source detail and the usage directive. The first sentence is dense but every clause earns its place; only the domain-specific parentheticals add mild weight.
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 values need not be spelled out. For a no-param informational tool, the description fully covers what it returns, that it needs no input, and how it fits before validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description reinforces this with "Takes no input," leaving nothing ambiguous about invocation.
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 (Returns) and resource (the fields of the Statement 3 JSON), scoped to a concrete domain output (RFD-01). It is clearly distinguishable from validate_statement3 and generate_statement3, which act on that data rather than enumerate its fields.
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 it before validate_statement3 to learn which fields to collect" gives explicit ordering and names the alternative it complements. It doesn't state when NOT to use it, but the context is unambiguous for a pre-validation discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one public guide as Markdown, with its source links and the date its sources were checked. Takes a slug from search_refund_guides.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| slug | Yes | |
| title | Yes | |
| topic | No | |
| checked | No | |
| markdown | Yes | |
| createFiles | No | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description adds valuable context about output format (Markdown) and that source links and a checked date are included, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: first states what is returned and its components, second explains the param source. Zero waste and 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?
With an output schema likely detailing the return structure, the description need not enumerate fields, but it helpfully mentions Markdown, source links, and checked date. Combined with annotations covering safety and a single parameter explained, the definition is nearly 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%, but with only one parameter (slug) the description successfully clarifies its origin (search_refund_guides). It doesn't repeat the pattern/maxLength from schema, but the origin is the key semantic the schema omits.
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 (Returns), resource (one public guide), and format (Markdown), plus two extra returned artifacts. It clearly distinguishes itself from search_refund_guides by naming it as the source of the slug.
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?
Tells the agent the slug comes from search_refund_guides, which implies the workflow (search then read). No explicit when-not-to-use guidance, but the context is clear for a single-param retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds Fast GST Refund's public guides by preparation topic and returns their slugs, titles and descriptions. Takes general keywords; it does not need taxpayer identifiers or document contents.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| guides | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and a closed (non-open-world) corpus. The description adds that the corpus is public guides and that no sensitive inputs are required, which is genuinely useful but not deep. Return values are covered by the output schema, so little else is owed.
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, and the primary function plus return shape is front-loaded before the input constraint. Nothing redundant with the annotations or schema is repeated.
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 values need not be explained, and the description confirms them anyway. For a read-only, non-open-world search tool the picture is largely complete, with the only gap being the undocumented 'limit' parameter and absent routing to read_refund_guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies that 'query' takes general keywords, but 'limit' is never mentioned and no format, matching behavior, or maxLength/pattern constraints are explained beyond what the raw schema shows.
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 (Finds), the exact resource (Fast GST Refund's public guides), the retrieval axis (by preparation topic), and the return shape (slugs, titles, descriptions). This clearly separates it from read_refund_guide, which presumably fetches a single guide.
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 contextually implies keyword search over public guides and rules out needing taxpayer identifiers or document contents, which is useful scoping. However, it never says when to prefer this over the sibling read_refund_guide (e.g., discover-then-read), so routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks records for the Annexure B JSON (statement of inward-supply invoices) for a GST refund of accumulated ITC (RFD-01), the file the GST portal otherwise requires from its Excel offline utility. Applies the offline utility's own checks and returns every error and warning at once, with its row and field. Free; needs no sign-in; stores nothing. A file made by the official utility can be passed as data unchanged. ITC eligibility, reversal amounts and GSTR-2B periods come from the taxpayer's reviewed records; the tool does not infer them.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The document's fields, as its requirements tool lists them, or a JSON file from the official utility unchanged. |
| Name | Required | Description |
|---|---|---|
| claim | No | |
| valid | Yes | |
| errors | Yes | |
| message | No | |
| summary | No | |
| document | Yes | |
| nextStep | No | |
| warnings | Yes | |
| inputFormat | No | |
| jsonVersion | No | |
| utilityVersion | No | |
| generatorVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description adds real operational context: free, no sign-in, stores nothing, and returns every error and warning at once with row and field. It also discloses a key boundary — ITC eligibility, reversal amounts and GSTR-2B periods are taken from the taxpayer's reviewed records and are not inferred.
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 is front-loaded and every sentence carries information (scope, behavior, cost/auth, input expectation, non-inference caveat). It is somewhat dense at four sentences, but there is no filler or repetition.
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 values need not be detailed, and the annotations cover safety semantics. The description still covers scope, side effects, auth/privacy, input expectations and inference boundaries — nothing needed to invoke it correctly 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% for the single 'data' parameter, so the baseline is 3. The description adds meaning beyond the schema by stating the official utility's file can be passed unchanged and that eligibility/reversal/period values are not inferred, clarifying what the caller must supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Checks records for the Annexure B JSON') and anchors it in the refund domain (RFD-01, inward-supply invoices). It is clearly distinguishable from siblings such as generate_annexure_b, get_annexure_b_requirements and validate_statement3.
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 establishes when it applies ('A file made by the official utility can be passed as data unchanged', validating before the portal requires it), which gives a clear operating context. It never explicitly names an alternative tool or states when NOT to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks records for the Statement 3 JSON for a GST refund of accumulated ITC on exports without payment of tax (RFD-01), the file the GST portal otherwise requires from its Excel offline utility. Applies the offline utility's own checks and returns every error and warning at once, with its row and field. Free; needs no sign-in; stores nothing. A file made by the official utility can be passed as data unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The document's fields, as its requirements tool lists them, or a JSON file from the official utility unchanged. |
| Name | Required | Description |
|---|---|---|
| claim | No | |
| valid | Yes | |
| errors | Yes | |
| message | No | |
| summary | No | |
| document | Yes | |
| nextStep | No | |
| warnings | Yes | |
| inputFormat | No | |
| jsonVersion | No | |
| utilityVersion | No | |
| generatorVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description adds real behavioral value beyond them: it returns every error and warning at once with row and field, requires no sign-in, stores nothing, and accepts official utility output unchanged.
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?
Dense but front-loaded: the resource and form are named first, then behavior, then cost/auth/storage in compact clauses. Every sentence earns its place, though the phrasing is somewhat packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, yet the description still characterizes them. Auth, storage, and input-compatibility concerns are all addressed, making it complete for a single-object validator.
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% for the single 'data' parameter, so the baseline is already 3+. The description adds meaning beyond the schema by clarifying that an official utility file can be passed unchanged and that it applies the utility's own checks.
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 (checks/validates) and resource (Statement 3 JSON for RFD-01 GST refund), and implicitly contrasts with siblings like generate_statement3 and get_statement3_requirements. An agent can distinguish it from validate_annexure_b by the named form.
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 usage ('Applies the offline utility's own checks', 'a file made by the official utility can be passed as data unchanged') but never states when to use this versus validate_annexure_b or get_statement3_requirements, nor any preconditions. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_receipt_allocation5 fields changedOutput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "arithmeticValid": {
+ "type": "boolean"
+ },
+ "currency": {
+ "type": "string"
+ },
+ "invoiceBalances": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "allocatedPaise": {
+ "type": "number"
+ },
+ "amountPaise": {
+ "type": "number"
+ },
+ "balancePaise": {
+ "type": "number"
+ },
+ "row": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "row",
+ "amountPaise",
+ "allocatedPaise",
+ "balancePaise"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "issues": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextStep": {
+ "type": "string"
+ },
+ "receiptBalances": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "allocatedPaise": {
+ "type": "number"
+ },
+ "amountPaise": {
+ "type": "number"
+ },
+ "balancePaise": {
+ "type": "number"
+ },
+ "row": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "row",
+ "amountPaise",
+ "allocatedPaise",
+ "balancePaise"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sources": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "properties": {
+ "allocatedPaise": {
+ "type": "number"
+ },
+ "invoicePaise": {
+ "type": "number"
+ },
+ "invoicesWithBalance": {
+ "type": "number"
+ },
+ "receiptPaise": {
+ "type": "number"
+ },
+ "receiptsWithBalance": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "unit": {
+ "type": "string"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "arithmeticValid",
+ "invoiceBalances",
+ "receiptBalances",
+ "issues"
+]explain_upload_error5 fields changedOutput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "checks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "document": {
+ "type": "string"
+ },
+ "issue": {
+ "type": "string"
+ },
+ "nextStep": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sourcesChecked": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "document",
+ "issue",
+ "title",
+ "checks",
+ "nextStep"
+]generate_annexure_b8 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / data / additionalPropertiesPrevious value: -{}New value: +trueInput schema / properties / data / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "claim": {
+ "additionalProperties": true,
+ "properties": {
+ "fromFp": {
+ "type": "string"
+ },
+ "gstin": {
+ "type": "string"
+ },
+ "paid": {
+ "type": "boolean"
+ },
+ "toFp": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "document": {
+ "type": "string"
+ },
+ "documents": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "expiresAt": {
+ "type": "string"
+ },
+ "file": {
+ "additionalProperties": true,
+ "properties": {
+ "bytes": {
+ "type": "number"
+ },
+ "content": {
+ "type": "string"
+ },
+ "downloadUrl": {
+ "type": "string"
+ },
+ "expiresAt": {
+ "type": "string"
+ },
+ "filename": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "mcpUri": {
+ "type": "string"
+ },
+ "mimeType": {
+ "type": "string"
+ },
+ "sha256": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "filename",
+ "sha256",
+ "downloadUrl"
+ ],
+ "type": "object"
+ },
+ "generatorVersion": {
+ "type": "string"
+ },
+ "inputFormat": {
+ "type": "string"
+ },
+ "jsonVersion": {
+ "type": "string"
+ },
+ "linkNote": {
+ "type": "string"
+ },
+ "linkStatus": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "nextStep": {
+ "type": "string"
+ },
+ "openUrl": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "open_link",
+ "payment_required",
+ "file_ready"
+ ],
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "utilityVersion": {
+ "type": "string"
+ },
+ "valid": {
+ "type": "boolean"
+ },
+ "warnings": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "document",
+ "valid",
+ "status"
+]generate_statement38 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / data / additionalPropertiesPrevious value: -{}New value: +trueInput schema / properties / data / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "claim": {
+ "additionalProperties": true,
+ "properties": {
+ "fromFp": {
+ "type": "string"
+ },
+ "gstin": {
+ "type": "string"
+ },
+ "paid": {
+ "type": "boolean"
+ },
+ "toFp": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "document": {
+ "type": "string"
+ },
+ "documents": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "expiresAt": {
+ "type": "string"
+ },
+ "file": {
+ "additionalProperties": true,
+ "properties": {
+ "bytes": {
+ "type": "number"
+ },
+ "content": {
+ "type": "string"
+ },
+ "downloadUrl": {
+ "type": "string"
+ },
+ "expiresAt": {
+ "type": "string"
+ },
+ "filename": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "mcpUri": {
+ "type": "string"
+ },
+ "mimeType": {
+ "type": "string"
+ },
+ "sha256": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "filename",
+ "sha256",
+ "downloadUrl"
+ ],
+ "type": "object"
+ },
+ "generatorVersion": {
+ "type": "string"
+ },
+ "inputFormat": {
+ "type": "string"
+ },
+ "jsonVersion": {
+ "type": "string"
+ },
+ "linkNote": {
+ "type": "string"
+ },
+ "linkStatus": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "nextStep": {
+ "type": "string"
+ },
+ "openUrl": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "open_link",
+ "payment_required",
+ "file_ready"
+ ],
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "utilityVersion": {
+ "type": "string"
+ },
+ "valid": {
+ "type": "boolean"
+ },
+ "warnings": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "document",
+ "valid",
+ "status"
+]get_annexure_b_requirements5 fields changedOutput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "accepted": {
+ "additionalProperties": true,
+ "properties": {
+ "amounts": {
+ "type": "string"
+ },
+ "dates": {
+ "type": "string"
+ },
+ "existingFiles": {
+ "type": "string"
+ },
+ "periods": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "checks": {
+ "type": "string"
+ },
+ "document": {
+ "type": "string"
+ },
+ "fieldRulesBySupplyType": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "generatorVersion": {
+ "type": "string"
+ },
+ "inputSchema": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "jsonVersion": {
+ "type": "string"
+ },
+ "limits": {
+ "additionalProperties": true,
+ "properties": {
+ "requestBytes": {
+ "type": "number"
+ },
+ "rowsPerFile": {
+ "type": "number"
+ },
+ "splitUploads": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "notIncluded": {
+ "type": "string"
+ },
+ "references": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "sha256": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "fields": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "fields",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "utility": {
+ "type": "string"
+ },
+ "utilityVersion": {
+ "type": "string"
+ },
+ "workflow": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "document",
+ "workflow",
+ "sources",
+ "inputSchema"
+]get_refund_checklist5 fields changedOutput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "checks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "createFiles": {
+ "type": "string"
+ },
+ "guides": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "need": {
+ "type": "string"
+ },
+ "needLabel": {
+ "type": "string"
+ },
+ "nextStep": {
+ "type": "string"
+ },
+ "records": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "reason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "stage": {
+ "type": "string"
+ },
+ "stageLabel": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "stage",
+ "need",
+ "title",
+ "summary",
+ "records",
+ "checks",
+ "nextStep"
+]get_statement3_requirements5 fields changedOutput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "accepted": {
+ "additionalProperties": true,
+ "properties": {
+ "amounts": {
+ "type": "string"
+ },
+ "dates": {
+ "type": "string"
+ },
+ "existingFiles": {
+ "type": "string"
+ },
+ "periods": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "checks": {
+ "type": "string"
+ },
+ "document": {
+ "type": "string"
+ },
+ "fieldRulesBySupplyType": {
+ "additionalProperties": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "generatorVersion": {
+ "type": "string"
+ },
+ "inputSchema": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "jsonVersion": {
+ "type": "string"
+ },
+ "limits": {
+ "additionalProperties": true,
+ "properties": {
+ "requestBytes": {
+ "type": "number"
+ },
+ "rowsPerFile": {
+ "type": "number"
+ },
+ "splitUploads": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "notIncluded": {
+ "type": "string"
+ },
+ "references": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "sha256": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "fields": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "fields",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "utility": {
+ "type": "string"
+ },
+ "utilityVersion": {
+ "type": "string"
+ },
+ "workflow": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "document",
+ "workflow",
+ "sources",
+ "inputSchema"
+]read_refund_guide5 fields changedOutput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "checked": {
+ "type": "string"
+ },
+ "createFiles": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "markdown": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "slug",
+ "title",
+ "url",
+ "markdown"
+]search_refund_guides5 fields changedOutput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "guides": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "sourcesChecked": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "guides"
+]validate_annexure_b8 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / data / additionalPropertiesPrevious value: -{}New value: +trueInput schema / properties / data / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "claim": {
+ "additionalProperties": true,
+ "properties": {
+ "fromFp": {
+ "type": "string"
+ },
+ "gstin": {
+ "type": "string"
+ },
+ "paid": {
+ "type": "boolean"
+ },
+ "toFp": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "document": {
+ "type": "string"
+ },
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "generatorVersion": {
+ "type": "string"
+ },
+ "inputFormat": {
+ "type": "string"
+ },
+ "jsonVersion": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "nextStep": {
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "utilityVersion": {
+ "type": "string"
+ },
+ "valid": {
+ "type": "boolean"
+ },
+ "warnings": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "document",
+ "valid",
+ "errors",
+ "warnings"
+]validate_statement38 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Input schema / properties / data / additionalPropertiesPrevious value: -{}New value: +trueInput schema / properties / data / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / additionalPropertiesPrevious value: -{}New value: +trueOutput schema / propertiesAdded value: +{
+ "claim": {
+ "additionalProperties": true,
+ "properties": {
+ "fromFp": {
+ "type": "string"
+ },
+ "gstin": {
+ "type": "string"
+ },
+ "paid": {
+ "type": "boolean"
+ },
+ "toFp": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "document": {
+ "type": "string"
+ },
+ "errors": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "generatorVersion": {
+ "type": "string"
+ },
+ "inputFormat": {
+ "type": "string"
+ },
+ "jsonVersion": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "nextStep": {
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "utilityVersion": {
+ "type": "string"
+ },
+ "valid": {
+ "type": "boolean"
+ },
+ "warnings": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "path",
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+}Output schema / propertyNamesRemoved value: -{
- "type": "string"
-}Output schema / requiredAdded value: +[
+ "document",
+ "valid",
+ "errors",
+ "warnings"
+]generate_annexure_b5 fields changedInput schema / properties / actionRemoved value: -{
- "default": "requirements",
- "description": "requirements: fields and sources. validate: check data. generate: create the file.",
- "enum": [
- "requirements",
- "validate",
- "generate"
- ],
- "type": "string"
-}Input schema / properties / data / descriptionPrevious value: -"The document fields from action=requirements, or a JSON file from the official utility unchanged. Omit for requirements."New value: +"The document's fields, as its requirements tool lists them, or a JSON file from the official utility unchanged."Input schema / properties / direct / descriptionPrevious value: -"With generate: true to have the file returned to this client. It needs the user's Fast GST Refund account to be connected; if it is not, the client is asked to sign in. Omit unless the user asked for the file here."New value: +"true to have the file returned to this client. It needs the user's Fast GST Refund account to be connected; if it is not, the client is asked to sign in. Leave out unless the user asked for the file here."Input schema / properties / link / descriptionPrevious value: -"With generate: the openUrl from the other generator's result, so that one link holds both files."New value: +"The openUrl from the other generate tool's result, so that one link holds both files."Input schema / requiredAdded value: +[
+ "data"
+]generate_statement35 fields changedInput schema / properties / actionRemoved value: -{
- "default": "requirements",
- "description": "requirements: fields and sources. validate: check data. generate: create the file.",
- "enum": [
- "requirements",
- "validate",
- "generate"
- ],
- "type": "string"
-}Input schema / properties / data / descriptionPrevious value: -"The document fields from action=requirements, or a JSON file from the official utility unchanged. Omit for requirements."New value: +"The document's fields, as its requirements tool lists them, or a JSON file from the official utility unchanged."Input schema / properties / direct / descriptionPrevious value: -"With generate: true to have the file returned to this client. It needs the user's Fast GST Refund account to be connected; if it is not, the client is asked to sign in. Omit unless the user asked for the file here."New value: +"true to have the file returned to this client. It needs the user's Fast GST Refund account to be connected; if it is not, the client is asked to sign in. Leave out unless the user asked for the file here."Input schema / properties / link / descriptionPrevious value: -"With generate: the openUrl from the other generator's result, so that one link holds both files."New value: +"The openUrl from the other generate tool's result, so that one link holds both files."Input schema / requiredAdded value: +[
+ "data"
+]get_annexure_b_requirementsget_statement3_requirementsvalidate_annexure_bvalidate_statement3generate_annexure_b8 fields changedInput schema / properties / action / descriptionAdded value: +"requirements: fields and sources. validate: check data. generate: create the file."Input schema / properties / data / additionalPropertiesPrevious value: -falseNew value: +{}Input schema / properties / data / descriptionAdded value: +"The document fields from action=requirements, or a JSON file from the official utility unchanged. Omit for requirements."Input schema / properties / data / propertiesRemoved value: -{
- "filename": {
- "description": "Unique upload filename without .json. Use a different filename for each part of a split upload.",
- "pattern": "^[A-Za-z0-9_-]{1,64}$",
- "type": "string"
- },
- "fromFp": {
- "description": "Refund return period mmyyyy.",
- "pattern": "^(0[1-9]|1[0-2])\\d{4}$",
- "type": "string"
- },
- "gstin": {
- "pattern": "^\\d{2}[A-Z]{5}\\d{4}[A-Z][1-9A-Z][Z1-9A-J][0-9A-Z]$",
- "type": "string"
- },
- "invoices": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "camt": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "catOfInv": {
- "enum": [
- "Inputs",
- "Input Services",
- "Capital Goods"
- ],
- "type": "string"
- },
- "cessamt": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "elgItc": {
- "enum": [
- "Yes",
- "No",
- "Partially"
- ],
- "type": "string"
- },
- "elgItcAmt": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "hsnSac": {
- "pattern": "^(?:\\d{4}|\\d{6}|\\d{8})$",
- "type": "string"
- },
- "iamt": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "idt": {
- "description": "Calendar date dd-mm-yyyy, not a future date.",
- "pattern": "^\\d{2}-\\d{2}-\\d{4}$",
- "type": "string"
- },
- "inelgItcAmt": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "inum": {
- "pattern": "^[A-Za-z0-9/-]{1,16}$",
- "type": "string"
- },
- "isItcBlocked": {
- "enum": [
- "Yes",
- "No",
- "Partially"
- ],
- "type": "string"
- },
- "istype": {
- "enum": [
- "Invoice/Bill of Entry",
- "Credit Note",
- "Debit Note"
- ],
- "type": "string"
- },
- "portCode": {
- "anyOf": [
- {
- "pattern": "^[A-Za-z0-9]{6}$",
- "type": "string"
- },
- {
- "const": "",
- "type": "string"
- }
- ]
- },
- "returnPeriod2B": {
- "description": "Actual GSTR-2B period mm-yyyy; empty for imported services (including SEZ) and unregistered RCM.",
- "pattern": "^(?:(?:0[1-9]|1[0-2])-\\d{4})?$",
- "type": "string"
- },
- "samt": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "snm": {
- "maxLength": 100,
- "minLength": 1,
- "type": "string"
- },
- "stin": {
- "anyOf": [
- {
- "pattern": "^\\d{2}[A-Z]{5}\\d{4}[A-Z][1-9A-Z][Z1-9A-J][0-9A-Z]$",
- "type": "string"
- },
- {
- "const": "",
- "type": "string"
- }
- ]
- },
- "typeOfInwardSupply": {
- "enum": [
- "Import of Goods",
- "Import of Services",
- "Import of Goods(Supplies from SEZ to DTA)",
- "Import of Services(Supplies from SEZ to DTA)",
- "Inward Supplies from Registered Persons",
- "Inward Supplies liable to Reverse Charge (Registered Persons)",
- "Inward Supplies liable to Reverse Charge (Unregistered Persons)",
- "Inward Supplies from ISD"
- ],
- "type": "string"
- },
- "val": {
- "description": "Allocated document value including tax for this category/HSN row. ISD must use 0.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- }
- },
- "required": [
- "typeOfInwardSupply",
- "istype",
- "stin",
- "snm",
- "inum",
- "idt",
- "portCode",
- "val",
- "catOfInv",
- "hsnSac",
- "camt",
- "samt",
- "iamt",
- "cessamt",
- "isItcBlocked",
- "elgItc",
- "elgItcAmt",
- "inelgItcAmt",
- "returnPeriod2B"
- ],
- "type": "object"
- },
- "maxItems": 10000,
- "minItems": 1,
- "type": "array"
- },
- "reversals": {
- "additionalProperties": false,
- "description": "Explicit GSTR-3B reversal amounts. Confirm all zero values. For multiple files put reversals only in the final file.",
- "properties": {
- "revCGST": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "revCess": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "revIGST": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "revOthCGST": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "revOthCess": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "revOthIGST": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "revOthSGST": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- },
- "revSGST": {
- "description": "Non-negative INR decimal string, max 15 integer digits and 2 decimals; e.g. 1180.50. No commas or currency symbol.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- }
- },
- "required": [
- "revCGST",
- "revSGST",
- "revIGST",
- "revCess",
- "revOthCGST",
- "revOthSGST",
- "revOthIGST",
- "revOthCess"
- ],
- "type": "object"
- },
- "toFp": {
- "description": "Refund return period mmyyyy.",
- "pattern": "^(0[1-9]|1[0-2])\\d{4}$",
- "type": "string"
- }
-}Input schema / properties / data / propertyNamesAdded value: +{
+ "type": "string"
+}Input schema / properties / data / requiredRemoved value: -[
- "gstin",
- "fromFp",
- "toFp",
- "filename",
- "reversals",
- "invoices"
-]Input schema / properties / directAdded value: +{
+ "description": "With generate: true to have the file returned to this client. It needs the user's Fast GST Refund account to be connected; if it is not, the client is asked to sign in. Omit unless the user asked for the file here.",
+ "type": "boolean"
+}Input schema / properties / linkAdded value: +{
+ "description": "With generate: the openUrl from the other generator's result, so that one link holds both files.",
+ "maxLength": 300,
+ "type": "string"
+}generate_statement38 fields changedInput schema / properties / action / descriptionAdded value: +"requirements: fields and sources. validate: check data. generate: create the file."Input schema / properties / data / additionalPropertiesPrevious value: -falseNew value: +{}Input schema / properties / data / descriptionAdded value: +"The document fields from action=requirements, or a JSON file from the official utility unchanged. Omit for requirements."Input schema / properties / data / propertiesRemoved value: -{
- "documents": {
- "items": {
- "oneOf": [
- {
- "additionalProperties": false,
- "properties": {
- "docType": {
- "enum": [
- "Invoice",
- "Debit Note",
- "Credit Note"
- ],
- "type": "string"
- },
- "idt": {
- "description": "Calendar date dd-mm-yyyy, not a future date.",
- "pattern": "^\\d{2}-\\d{2}-\\d{4}$",
- "type": "string"
- },
- "inum": {
- "pattern": "^[A-Za-z0-9/-]{1,16}$",
- "type": "string"
- },
- "type": {
- "const": "S",
- "type": "string"
- },
- "val": {
- "description": "Document value in INR as reported for this export document, as a decimal string.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- }
- },
- "required": [
- "docType",
- "inum",
- "idt",
- "val",
- "type"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "docType": {
- "enum": [
- "Invoice",
- "Debit Note",
- "Credit Note"
- ],
- "type": "string"
- },
- "egmref": {
- "pattern": "^[A-Za-z0-9]{1,20}$",
- "type": "string"
- },
- "egmrefdt": {
- "description": "Calendar date dd-mm-yyyy, not a future date.",
- "pattern": "^\\d{2}-\\d{2}-\\d{4}$",
- "type": "string"
- },
- "fobValue": {
- "description": "INR FOB decimal string, at most 15 integer digits and 4 decimals.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,4})?$",
- "type": "string"
- },
- "idt": {
- "description": "Calendar date dd-mm-yyyy, not a future date.",
- "pattern": "^\\d{2}-\\d{2}-\\d{4}$",
- "type": "string"
- },
- "inum": {
- "pattern": "^[A-Za-z0-9/-]{1,16}$",
- "type": "string"
- },
- "sbdt": {
- "description": "Calendar date dd-mm-yyyy, not a future date.",
- "pattern": "^\\d{2}-\\d{2}-\\d{4}$",
- "type": "string"
- },
- "sbnum": {
- "pattern": "^\\d{3,7}$",
- "type": "string"
- },
- "sbpcode": {
- "pattern": "^[A-Za-z0-9]{6}$",
- "type": "string"
- },
- "type": {
- "const": "G",
- "type": "string"
- },
- "val": {
- "description": "Document value in INR as reported for this export document, as a decimal string.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- }
- },
- "required": [
- "docType",
- "inum",
- "idt",
- "val",
- "type",
- "sbpcode",
- "sbnum",
- "sbdt",
- "fobValue",
- "egmref",
- "egmrefdt"
- ],
- "type": "object"
- }
- ]
- },
- "maxItems": 10000,
- "minItems": 1,
- "type": "array"
- },
- "fromFp": {
- "description": "Refund return period mmyyyy.",
- "pattern": "^(0[1-9]|1[0-2])\\d{4}$",
- "type": "string"
- },
- "gstin": {
- "pattern": "^\\d{2}[A-Z]{5}\\d{4}[A-Z][1-9A-Z][Z1-9A-J][0-9A-Z]$",
- "type": "string"
- },
- "receipts": {
- "description": "Separate aggregate BRC/FIRC rows, not nested under invoices. Use [] for goods-only statements without receipts.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "dt": {
- "description": "Calendar date dd-mm-yyyy, not a future date.",
- "pattern": "^\\d{2}-\\d{2}-\\d{4}$",
- "type": "string"
- },
- "num": {
- "description": "BRC/FIRC reference; portal guide's 3–30 alphanumeric limit (workbook allows 2).",
- "pattern": "^[A-Za-z0-9]{3,30}$",
- "type": "string"
- },
- "val": {
- "description": "INR amount supported by this receipt for the statement. Do not repeat the full receipt amount across invoices.",
- "pattern": "^(?:0|[1-9]\\d{0,14})(?:\\.\\d{1,2})?$",
- "type": "string"
- }
- },
- "required": [
- "num",
- "dt",
- "val"
- ],
- "type": "object"
- },
- "maxItems": 10000,
- "type": "array"
- },
- "toFp": {
- "description": "Refund return period mmyyyy.",
- "pattern": "^(0[1-9]|1[0-2])\\d{4}$",
- "type": "string"
- }
-}Input schema / properties / data / propertyNamesAdded value: +{
+ "type": "string"
+}Input schema / properties / data / requiredRemoved value: -[
- "gstin",
- "fromFp",
- "toFp",
- "documents",
- "receipts"
-]Input schema / properties / directAdded value: +{
+ "description": "With generate: true to have the file returned to this client. It needs the user's Fast GST Refund account to be connected; if it is not, the client is asked to sign in. Omit unless the user asked for the file here.",
+ "type": "boolean"
+}Input schema / properties / linkAdded value: +{
+ "description": "With generate: the openUrl from the other generator's result, so that one link holds both files.",
+ "maxLength": 300,
+ "type": "string"
+}generate_annexure_bgenerate_statement3check_receipt_allocationexplain_upload_errorget_refund_checklistread_refund_guidesearch_refund_guidesDeterministic Schedule III statements for Indian companies: trial balance in, Excel workbook out.
PDF tools + invoice extraction, bank statement parsing, GST reconciliation & GSTIN validation.
Validate Indian GSTINs locally (Verhoeff), extract PAN, identify issuing state.
Convert PDF bank statements to checked Excel, CSV or JSON with balance validation.
Add one secure layer between your agents and this server.
