Indian Cyber Regulation Register (BitScore)

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

Annotations only cover the read-only/idempotent/closed-world profile; the description goes well beyond that by disclosing the shape of the answer (instruments, why each applies, a caution flag, next deadline) and by calling out edge-case behavior for entity classes with no applicable instruments. That is exactly the return-contract detail an agent needs 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?

Two sentences, front-loaded with the input-to-output mapping, and the second sentence handles exceptions. The clause chain in sentence two ('why each applies, a caution..., and its next dated deadline') is dense but each clause conveys a distinct output field, so little is wasted.

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 full burden of describing the return value, and it does so precisely, including the per-class exception behavior. Nothing an agent needs to select or call this three-parameter tool 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% and the schema already explains the regulatory consequence of each flag (LODR disclosure, DPDP). The description restates the same three inputs without adding syntax, defaults, or interaction rules, 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?

The description gives a specific verb ('returns') plus the exact inputs consumed (entity class, listed status, personal-data handling) and the exact payload produced (binding instruments, reasons, misapplication caution, next dated deadline). The Indian scope cleanly separates it from the sibling find_global_cyber_regulations 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?

The preconditions for calling are clear from the enumerated inputs, and edge-case guidance is given (RBI classes map to their own 2026 Directions; RRBs and LABs have none and the result says so). It never explicitly states when NOT to use it or points to a sibling tool for out-of-scope cases, so it stops short of a 5.

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 this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuine value beyond that by disclosing the returned structure: applicability classification per regime plus a 'why' and a 'caution' for each.

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 scope and operator profile, second sentence covering defaults. Dense but every clause carries information; 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?

With no output schema, the description must explain returns, and it does: applicability status, rationale, and a caution per regime. Combined with the fully-covered input schema, an agent has enough to invoke and interpret the result, though the sibling overlap remains unresolved.

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% across all 17 parameters, so the schema already documents each flag, enum, and boolean. The description only adds default-value behavior, which is marginal, so the baseline 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 (lists) and resource (cyber and data-protection regimes) with geographic scope and output classification (applies / may apply / pending). It does not distinguish itself from the close sibling find_applicable_regulations, so it falls short of a 5.

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 note that 'all flags default to false and sizes/sectors to none' implies the tool can be called with no arguments for a baseline scan, which is useful. However, there is no explicit when-to-use guidance and no routing against find_applicable_regulations, so usage is only implied.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses that the record is the 'full register entry' with dated deadlines and a source URL plus last-verified date, which signals data freshness semantics the annotations do not convey.

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 sentence, front-loaded with the verb and resource, then the payload contents. No filler, no restatement of the tool name or annotations.

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, so the description must carry the return-value burden, and it does so by enumerating the fields an agent will receive. Combined with annotations covering safety, an agent has everything needed to call it correctly and anticipate the response shape.

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?

With 100% schema coverage on a single parameter, the baseline is 3, and the schema example ids already document format. The description still adds provenance meaning by stating the id comes from search_instruments, clarifying that this is not an arbitrary identifier but a register key produced by the sibling tool.

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 (get) and resource (one instrument from the register) and enumerates the returned content: formal name, reference, issue date, status, bindings, deadlines, regulator URL, last-read date. It also distinguishes itself from search_instruments by noting the id's provenance, so an agent can tell it apart from the sibling search 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?

It explicitly says the id comes 'from search_instruments', which routes the agent to the correct upstream tool and implies this is a follow-up detail lookup rather than a discovery call. It stops short of stating when NOT to use it (e.g., for bulk retrieval use search_instruments), so it is clear context without explicit exclusions.

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 read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds real context beyond that: the parallel-clock semantics, the non-discharge rule, and the dependency of wall-clock output on noticed_at.

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 with no filler; the scope enumeration comes first and the operational instruction follows. Slightly packed but every clause carries 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?

With no output schema, the description carries the burden of describing the return shape and does so: each clock comes with trigger, recipient, channel and source clause, plus computed due times. Nothing essential for correct invocation 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% and each of the 10 parameters is documented, so the baseline is 3. The description earns one above baseline by explaining the effect of noticed_at (conversion to IST due times) rather than merely restating its schema text.

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 computed artifact (Indian incident-reporting clocks) and enumerates the regimes it covers (CERT-In, RBI, SEBI, IRDAI, IFSCA, LODR, NCIIPC, DPDP), which cleanly separates it from the sibling us_eu_incident_reporting_deadlines.

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?

States the operative input condition clearly: supply noticed_at to get wall-clock IST due times. It also warns that clocks run in parallel and none discharges another, which shapes how results should be used. It stops short of naming when to prefer a sibling tool.

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 genuinely useful behavioural context beyond that: results are aggregate only, no organisation is named, and an uncovered vertical is 'unmeasured, not zero' — a data-interpretation caveat an agent could not infer from 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?

Three tight sentences, front-loaded with what is returned and how it is scoped, followed by the aggregate-only caveat and the unmeasured-not-zero clarification. No sentence is 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?

With no output schema, the description carries the burden of describing returns, and it does so adequately: aggregate counts by vertical and category, per edition, anonymised. The only residual gap is that it doesn't indicate result shape beyond 'counts', but for a single-parameter read tool this is close to 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 100% and the single enum parameter is fully documented in the schema with its YYYY-MM format and omit-for-latest behaviour. The description adds no syntax beyond what the schema already provides, so the baseline of 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 (aggregate) plus resource (publicly observed cyber threat activity affecting Indian organisations) and the dimensions of aggregation (industry vertical and category). It is unmistakably distinct from the sibling tools, which all deal with regulations and reporting deadlines rather than threat counts.

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 the selection context explicit — one edition, latest by default — which tells the agent how to invoke it correctly. It does not name an alternative tool or state when to prefer a sibling, so it stops short of the top score.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: it discloses the return shape ('Returns summaries') for a tool with no output schema, and names the corpus boundary that makes the search closed-world.

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 verb and scope, then the alternatives. The regulator enumeration is dense but it is exactly the scope information the agent needs; no sentence is 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?

With no output schema present, the description correctly discloses that results are summaries and points to get_instrument for full text, which is the key completeness requirement. Minor omission: nothing in prose about result-size/pagination behavior, though the limit parameter documents that in the schema.

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 both enums are fully documented, so the schema carries the parameter burden. The description's 'filter by free text, issuer or status' restates the schema's three filters without adding syntax, defaults, or matching semantics beyond what is already declared.

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 (search) plus the exact resource scope: 'every cyber and data-protection instrument binding Indian regulated entities' with the six named issuers. It enumerates the fields surfaced (reference number, issue date, status, who it binds, deadlines) and explicitly distinguishes itself from get_instrument, so an agent can route 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?

Gives clear usage context ('Filter by free text, issuer or status') and names the alternative plus its condition: 'use get_instrument for one entry in full.' It stops short of differentiating from the other search siblings (find_applicable_regulations, find_global_cyber_regulations), so there is no explicit exclusion set.

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 readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuine behavioral context: the boundary-value policy ("reported as such, not guessed") and that obligations are returned alongside the category. It does not describe response structure or the shape of the obligations, 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, no filler, and the outcome is front-loaded before the invocation hint and the boundary-value caveat. Every clause carries 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?

With no output schema, the description must signal what comes back, and it does: the category plus the obligations attached to it, and a clear stance on uncategorised boundary values. It stops short of describing the structure of the obligations, but an agent has enough to 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 description coverage is 100% and each criterion parameter is self-documented with units, so the baseline is 3. The description contributes only the meta-rule that entity_type determines which of the seven figures are required — useful framing but not per-parameter semantics 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 (works out), resource (SEBI CSCRF category), and enumerates the full output space (MII, Qualified, Mid-size, Small-size, Self-certification, Exempt) plus the derived obligations. Nothing about this overlaps with the sibling tools, which are search/lookup oriented.

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?

"Call with only entity_type to see which figures it needs" gives explicit, actionable invocation guidance for the progressive-disclosure pattern. It doesn't name an alternative tool or say when-not to use it, but the siblings are unrelated enough that this is a minor gap.

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 readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds one genuinely useful behavioral fact: each regime's clock runs from its own distinct trigger, which explains why multiple date inputs matter. It does not describe the shape of the returned deadlines or how regimes with no applicable clock are represented.

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 tightly packed sentences, front-loaded on scope before the input instruction. The regime list is long but each item is a distinct covered framework, so it earns its space, though it reads as a run-on enumeration.

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 12-parameter read-only calculator with no output schema, the description covers scope and required date inputs adequately, but it leaves the returned result unexplained — whether the output is a per-regime due timestamp, a list, or a status when a regime does not apply. That gap matters because no output schema exists to fill 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 description coverage is 100% and all twelve parameters (including four enums) are documented in-schema, so the baseline is 3. The description adds only a light gloss on aware_at and decided_at ('for materiality/classification clocks'), largely restating what the schema already says about those fields.

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 names a concrete output (incident-reporting clocks / wall-clock due times) and enumerates the specific regimes it covers (SEC 8-K/6-K, NYDFS Part 500, the 36-hour bank rule, HIPAA, FTC Safeguards, NIS2, DORA, GDPR, CRA), which clearly separates it from sibling tools like find_applicable_regulations or india_incident_reporting_deadlines. It never names a sibling explicitly, so the differentiation is by subject matter rather than by contrast.

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 second sentence gives input guidance ('Give aware_at (and decided_at...)'), which is invocation detail rather than when-to-use guidance. There is no statement of when this tool is preferable to find_applicable_regulations, find_global_cyber_regulations, or the india equivalent, and no exclusions or prerequisites.

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