Setu.Anantasutra: Agent Tools API

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

Beyond the read-only/idempotent annotations, it discloses that the tool fetches and applies RFC 9309 matching, caps extra path testing at five, reports the deciding rule and Content-Signal preferences, and — critically — that each call costs $0.01 via x402 payment. Cost and payment mechanism are behavior an agent must know before invoking and are not captured in 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 sentences, front-loaded with what is read and what is reported, then the use case, then pricing. The first sentence is long but every clause (crawler list, path cap, deciding rule, Content-Signal) carries real information.

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

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

No output schema exists, and the description compensates by stating exactly what is returned per crawler: allow/deny for root plus extra paths, the deciding rule, and Content-Signal preferences. Combined with the disclosed cost, an agent has everything needed to decide and call 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; the description earns more by adding the constraint that only up to five extra paths are tested, which the schema does not state (it only caps length at 600 characters). Domain input semantics are left entirely to 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 and resource ('Reads a domain's robots.txt ... reports ... for each known AI crawler') with concrete scope (site root plus up to five extra paths, deciding rule, Content-Signal preferences). The resource and evaluation standard (RFC 9309) make it clearly distinct from a sibling like llms_txt_check without needing to name it.

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 a concrete motivating scenario: 'Use it to see whether a site is open to AI search but closed to AI training.' That tells the agent when the tool's answer matters, but there is no explicit exclusion or mention of when a sibling (e.g. llms_txt_check or geo_audit) would be preferred.

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, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the return shape (0-100 score, grade, prioritised recommendations) and the $0.02 per-call x402 payment requirement, which an agent must know before invoking.

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 purpose, then the enumerated signals, then the return value, intended use, and price — each clause carries distinct information with no filler. The signal list is long but is the substantive payload the agent needs to judge relevance.

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 steps in to describe the return (score, grade, recommendations), and it discloses the payment model and audit scope. An agent has everything needed to decide to call it, form the URL argument, and anticipate cost and result.

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

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

Schema description coverage is 100% and the single parameter already documents that a URL or bare domain is accepted with an example. The description adds only the scope constraint "one web page" — no syntax or normalization details beyond the schema, so 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 — auditing one web page's visibility to AI search engines — and enumerates exactly what is inspected (crawler rules, llms.txt, sitemap, on-page signals). This clearly distinguishes it from narrower siblings like llms_txt_check and ai_crawler_matrix, which cover only one slice of what is audited here.

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 to check or monitor a site for generative-engine optimisation" gives a concrete usage context and implies repeated/monitoring use. It stops short of naming alternatives or exclusions (e.g. when to prefer llms_txt_check for a single-file check), so it is clear but not fully routing.

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 read-only, idempotent and non-destructive, but the description adds substantial context they do not carry: offline operation, check-digit verification only where the algorithm is public (GSTIN), Aadhaar refusal, price per call with x402 payment, and that blank values are rejected uncharged. That is genuinely useful operational disclosure for an agent deciding whether to call and what it will cost.

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?

Information-dense but front-loaded: what it validates, then the special behaviors, then pricing. Every clause carries content, though the single run-on block could be broken up for easier scanning.

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?

No output schema exists, and the description compensates partially by naming the decoded fields (state, PAN holder type, company type) an agent can expect. It stops short of describing the actual response shape (success/failure indication, field names, error format), which would matter for a validation tool.

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 parameters and the enum fully documented in the schema, so the description only needs to add marginal meaning. It reiterates auto-detection and the accepted "type:" prefix, which are already in the schema; no extra syntax or normalization rules are supplied beyond that.

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 (validate/decode one Indian identifier) and enumerates the exact identifier types covered, so an agent knows precisely what falls inside its scope. The singular scope implicitly separates it from india_id_validate_batch.

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 a concrete usage context ("clean or pre-check form and invoice data") and states the Aadhaar exclusion, which is a real when-not rule. It never names the batch sibling as the alternative for multi-value work, so the routing decision between the two 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?

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.

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

Annotations already cover read-only, idempotent, open-world safety. The description adds genuinely new behavioral facts: it respects robots.txt, performs soft-404 detection, checks size, and costs $0.005 per call via x402 payment. It does not describe what the response looks like, which matters 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?

Front-loaded with the core check, then validation criteria, then usage timing and pricing. Dense but nearly every clause carries information; the enumerated validation rules are slightly compressed into one long sentence.

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?

No output schema exists, so the description should imply return content; it enumerates the checks (H1, blockquote summary, H2 sections, link lists, soft-404, size) which indirectly signals results, but it never states the response shape (pass/fail, findings list). Otherwise complete for a single-parameter read tool.

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

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

Schema coverage is 100% and there is only one parameter, which the schema already documents with an example. The description adds no format or edge-case meaning beyond 'domain', so the 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 specific verb and resource: checks whether a domain publishes /llms.txt and /llms-full.txt and validates structure against the llmstxt.org spec. The scope (presence + structure validation) clearly separates it from siblings like geo_audit or ai_crawler_matrix.

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 or after publishing an llms.txt file" gives a concrete trigger context. It does not name an alternative tool or state when not to use this one, 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.