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

Annotations already cover read-only/idempotent/non-destructive, yet the description adds genuinely new behavior: the 50-item cap, mixed-type acceptance, flat $0.02 x402 pricing, per-item results plus type/validity counts, and that Aadhaar-like batches are rejected without charge. That last detail is exactly the kind of rejection-and-billing nuance annotations cannot express.

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?

Opens with the identity and limit, then types, then return shape, then use cases, then pricing/rejection rules — front-loaded and dense, with essentially no filler sentences.

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

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

There is no output schema, and the description fills that gap by describing the return shape (one decoded result per item plus counts by type and validity). It also covers cost, payment mechanism, limits, and the Aadhaar rejection edge case, leaving nothing an agent needs before calling.

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 meaning beyond the schema by making explicit that mixed types are allowed in one batch and that a batch-level default type exists. The 50-value cap merely restates schema maxItems.

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 ('Batch version of the Indian identifier validator'), enumerates the supported identifier types, and explicitly positions itself as the batch counterpart to the sibling india_id_validate. An agent can distinguish it from the single-validator sibling without opening 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?

Gives concrete usage contexts ('cleaning vendor lists, invoices or onboarding data') and implies the batch/single split by calling itself the 'batch version'. It never explicitly says to use india_id_validate for lone values or what threshold favors batching, so routing is inferred rather than stated.

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