calculate_stamp_duty

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds a genuine disclaimer ('Not legal advice. Consult a qualified advocate.') and names the surcharge components, but the 'Returns: Standard envelope' line largely duplicates the existing output schema. No auth, rate-limit or error behavior is disclosed.

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

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

Front-loaded purpose sentence followed by usage, Args, Returns and Notes in a scannable layout. The Args section is somewhat redundant with the schema, which keeps it out of the top band, but nothing is padded or misleading.

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, idempotent calculation tool with a full output schema, the definition covers purpose, trigger, inputs, output shape and a legal disclaimer. Minor gaps remain: no statement of which jurisdictions are supported or what happens on an unsupported state/instrument combination.

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 three parameters including the INR unit and the MH/DL/KA and conveyance/lease/agreement examples. The Args block in the description restates this with no added syntax, validation rules, or formatting guidance, so baseline 3 applies.

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

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

The description gives a specific verb and resource: 'Calculate state stamp duty for various instruments.' That is unambiguous against the wider sibling set (court fee, GST, income tax, TDS). It never names or contrasts a nearest alternative such as calculate_court_fee, so it falls just short of the top band.

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 when estimating the stamp duty payable on legal documents like conveyance or lease' gives a clear triggering context. There are no exclusions, prerequisites (e.g. which states are supported), or alternative-tool routing, which is why it is not a 5.

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