Pro UPI QR

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety needs no explanation. With no output schema, the description carries the return-value burden and does it well by showing the exact rendered string, including the "Rupees and ... Paise Only" phrasing and paise handling. It doesn't say what happens for values over the ceiling or with more than two decimals.

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

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

Two sentences, front-loaded with the purpose, and the second sentence is a worked example that does real spec work rather than padding. Nothing extraneous.

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

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

For a one-parameter formatter with no output schema, the description plus schema covers what an agent needs: purpose, convention, range, and the exact output shape. Only edge cases (zero, negative, over-limit amounts) are 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?

The single parameter has 100% schema description coverage including the ₹99,99,99,999.99 ceiling, so the baseline is 3. The example input (125050.50) confirms the accepted numeric form, but the description adds no guidance on the string variant the schema also allows.

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

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

States a specific verb+resource (write a rupee amount in words) and pins down the numbering convention (lakh/crore, Indian way). The worked example makes it unmistakable and clearly separates it from the sibling calculators, which compute rather than format.

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?

"as on invoices, receipts and cheques" gives a clear context in which this formatting is the right choice, which is enough to route an agent here instead of to calculate_gst or calculate_upi_mdr. It stops short of naming exclusions or an alternative formatter, so it isn't a full when/when-not statement.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely new behavioral information by promising paisa-exact results, which tells the agent about rounding/quantization behavior absent from the schema. It stops short of describing the exact response shape, which matters with no output schema.

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

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

A single dense sentence that front-loads the verb and resource, then layers the two modes and the tax split in dependency order. No filler or restated title 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?

Complete enough to call correctly: inputs, defaults, modes, and precision are all clear. The remaining gap is the return shape (whether it returns the split components, total, and rate breakdown), which an agent must infer 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%, with both enum values, defaults, and formats already documented, so the schema carries the load. The description reinforces the semantic mapping (supply → CGST/SGST vs IGST, inclusive vs exclusive pricing) but adds no syntax or edge-case detail beyond what the schema states; 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?

States a specific verb and resource (calculate Indian GST) plus the two operations it supports: adding GST to a pre-tax price or extracting it from an inclusive price. The CGST/SGST vs IGST split further distinguishes its domain from all sibling calculators, which cover unrelated finance topics.

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 frames the two usage modes — add GST to a price before tax, or take it out of a GST-inclusive price — and ties intra-state vs inter-state to the correct tax split. It doesn't name sibling tools or state exclusions, but the siblings are unrelated calculators, so the routing risk is low.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantive computation context: three times the RBI Bank Rate (17.25%), monthly compounding, and the accrual start (day after the payment deadline). It does not state the output shape or rounding/format behavior beyond 'exact to the paisa'.

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

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

A single well-packed sentence: purpose first, then the formula, rate, compounding, and accrual window, closing with precision. Every clause carries information an agent or user needs, with no repetition of schema 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?

For a deterministic read-only calculator with no output schema, the description covers the computation method and precision well enough to call it correctly. The only residual gap is the return value's exact shape (numeric amount vs. formatted currency), which 'exact to the paisa' only hints at.

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 all four parameters, including the 45-day cap and the paid_on default. The description adds only the accrual start logic tied to invoice date, which is marginal over what the schema provides; baseline 3 is appropriate.

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 precise verb+resource (calculate MSMED late-payment interest) and pins the domain with the exact legal basis, Section 16 of the MSMED Act, and the payer/payee roles. An agent can distinguish it from calculate_gst or calculate_upi_mdr 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?

Implies the triggering situation clearly: a buyer paying a Udyam-registered micro/small supplier late, past the agreed credit period (max 45 days). It does not name an alternative tool or state explicit exclusions, but the domain conditions are specific enough that an agent knows when it applies.

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 this as a safe, read-only, idempotent calculation. The description adds substantial behavioral context beyond that: threshold rules, caps, flat fees, zero-rated cases, GST treatment, and what the merchant keeps. It does not fully specify return shape, but with no output schema it gives more transparency than most calculators.

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 one dense paragraph but is front-loaded with purpose and then lists the relevant rules efficiently. Every clause carries rule information, though the single-sentence structure is slightly harder to scan than a short bulleted rule list would be.

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 read-only calculator with no output schema, the description supplies the key inputs, thresholds, and a summary of what the result shows ('18% GST on the MDR and what the merchant keeps'). It does not enumerate every possible output field, but it is complete enough for an agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds business meaning by explaining how category values affect the result: standard 0.4%, essential ₹5, capital 0.02%, and p2p zero. It also ties gst_registered and small_merchant to the 18% GST and ₹1 lakh monthly threshold, adding interpretation beyond the field descriptions.

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 ('Work out the UPI merchant discount rate (MDR) on a payment') and immediately clarifies the legal rule set and effective date. An agent can tell this is a single-payment MDR calculator, not a GST calculator or payment-link tool.

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 makes clear the context is one UPI payment under the 15 October 2026 rules, which implies when to use it. However, it does not explicitly name alternatives such as calculate_gst or state exclusions, so sibling routing is left to inference.

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

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

The description adds substantial behavior beyond the annotations: it explains the upi://pay deep link format, which apps open it, what is returned (link plus a proupiqr.in page with QR code and printable poster), that amounts are exact to the paisa, that nothing is stored, and that it never moves money. These details meaningfully clarify the operation and align with the read-only, non-destructive annotations.

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

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

The description is front-loaded with the core action and resource, then adds just enough detail about use cases, return value, precision, and safety. Every sentence earns its place without repetition or waste.

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, but the description fully covers what the tool returns and how the link behaves. It also discloses the no-money-movement and no-storage behavior, so an agent has enough context to call it correctly alongside the existing annotations.

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. The description adds only light context, such as that the UPI ID is Indian and amounts are exact to the paisa; it does not need to explain parameter syntax given the schema, so the baseline of 3 is appropriate.

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: create a UPI payment link for an Indian UPI ID, and explains what the resulting link does. It is clear, but it does not explicitly distinguish itself from sibling tools such as generate_upi_qr_code or read_upi_link, which could be confused with the QR-return behavior mentioned.

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 concrete usage contexts: collect a payment, split a bill, or put on an invoice. However, it does not say when not to use it or name alternatives like generate_upi_qr_code or read_upi_link, so the guidance is clear but not complete.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real context beyond that by specifying the substance of the answer (cause side, debit status, refund timing, recommended action) and the coverage limit of 42 codes. It doesn't say how an unrecognized code is handled, 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?

Two sentences, no filler. The action and the return content are front-loaded in the first sentence, and the coverage note is a compact closing qualifier. The parenthetical example list is dense but earns its place by clarifying accepted input forms.

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

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

With no output schema, the description carries the burden of describing the response, and it does so by naming the five things the answer contains. It is nearly complete for a single-parameter lookup; the missing piece is what the tool returns for a code it doesn't recognize.

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% for the single `code` parameter, so the schema already explains that it accepts a code or words from the error message. The description reinforces this with additional example values but adds no new semantics such as casing, formatting, or ambiguity handling. 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?

States a specific verb (explain) and resource (a failed UPI payment error code or message) and enumerates the exact outputs an agent can expect: meaning, originating side, debit status, return timing, and next steps. This is clearly distinct from every sibling, which are calculators, generators, and link readers.

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 examples (U30, ZM, XH, Z9, U16, or a message phrase like "debit has been failed") and the scope statement "Covers 42 common NPCI and bank codes" make the input domain and appropriate situation clear. It stops short of stating when not to use it or what happens for codes outside those 42, but no sibling overlaps enough to require an explicit alternative.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds meaningfully on top: results come back as links and the tools run in the browser with no signup required. That no-auth, in-browser behavior is useful context an agent would not get from the annotations, and there is no output schema to supply it.

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 purpose leads and the return/behavior note follows. The long category enumeration in the first sentence is slightly keyword-dump-like but does real work by signaling search breadth, so it mostly 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, fully annotated read tool with no output schema, the description covers purpose, result form, and no-signup behavior. It leaves a gap on how this search relates to the sibling action tools (generate/calculate), which an agent needs in order to place it correctly in a workflow.

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%, with both `query` (including examples) and `limit` (default 5, max 10) fully documented in the schema. The description's list of task categories loosely enriches what a valid query looks like, but adds no format, ranking, or result-count guidance beyond the schema, 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?

States a concrete verb + resource: 'Find the free Pro UPI QR tool for a task', and lists the task domains (invoices, receipts, GST/MSME tools, UPI QR posters) that the catalog covers. It is distinguishable from the calculator/generator siblings, though the opening 'Find the free Pro UPI QR tool' is slightly narrower-sounding than the broad catalog it actually searches.

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 task list implies when to reach for it (discovering a tool for a producing/task need), but there is no explicit when-not or routing guidance. An agent could plausibly call generate_upi_qr_code or calculate_gst directly instead, and the description never says whether this tool is a discovery step that precedes those, which leaves real ambiguity.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: nothing is persisted, no money moves, and the payer approves in their own app. It also discloses the full set of return artifacts (PNG, upi:// link, printable poster page) that the agent would otherwise not know about, since there is no output schema.

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 sentences, front-loaded with the core output and use case, then the side artifacts, then the safety boundary. Minor redundancy in "PhonePe, Google Pay, Paytm, BHIM and every UPI app can scan," where the enumeration largely restates "every UPI app."

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

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

With no output schema, the description carries the burden of describing returns and does so explicitly (PNG image, upi:// link, download page). Combined with the no-storage/no-money-movement disclosure for a read-only tool, an agent has everything needed to call it and set payer expectations.

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 five parameters including the amount/note optionality and size default are already documented in the schema. The description only restates that amount and note are optional, adding no format or constraint detail beyond the structured fields — the 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?

States a specific verb and resource ("Generate a UPI payment QR code (PNG image)") plus the scope: an Indian UPI VPA, optional fixed amount and note. It is clearly separable from siblings like create_upi_payment_link and read_upi_link, since the output is a scannable image artifact rather than a link record.

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?

"Optionally with a fixed amount and note... Leave it out and the payer types the amount" gives clear context for the two modes of use, and "Nothing is stored. It never moves money" rules out the collection/settlement use case. It never explicitly names an alternative sibling or says when to prefer create_upi_payment_link instead, 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.

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value beyond that by stating the inspection output (payee, amount, note, merchant fields) and that it emits warnings for risky patterns like an AutoPay mandate posing as a payment. It doesn't say how warnings are surfaced (severity levels, pass/fail verdict), which keeps it below 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: the first front-loads what is read and what is returned, the second gives usage. Every clause carries information (payee, amount, note, merchant fields, risk warnings, AutoPay caveat) 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?

For a one-parameter, read-only, no-output-schema tool, the description covers purpose, output content, risk warnings and usage triggers. The only gap is how the check result is shaped (verdict vs. list of warnings), which matters since no output schema exists to describe it.

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 `link` parameter, and the schema description already says it is the upi://pay?… text decoded from a QR. The description only restates the format and adds the example context, so it neither compensates for a gap nor adds much beyond structured data — baseline 3.

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

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

Specific verb + resource ('Read a UPI payment link… and check it') plus an enumeration of exactly what is extracted (payee, amount, note, merchant fields) and flagged (malformed/risky data, AutoPay mandate disguised as a payment). This clearly separates it from create_upi_payment_link and generate_upi_qr_code, which produce links/QRs rather than inspecting them.

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 two concrete trigger scenarios: 'before paying from a QR someone sent' and 'to find out why apps reject a QR'. It stops short of explicitly naming the alternative sibling (explain_upi_error) for the rejection-diagnosis case, so the routing between this tool and that one is left to inference.

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