LiquiLens — the Failure Radar

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

Annotations already cover read-only, idempotent, closed-world and non-destructive, so the bar is lower, and the description still adds real context: outputs are 'cited', provisional updates are 'separately dated', and the tool carries 'no score, credit or execution authority'. Those are useful disclosure about provenance and epistemic status that the annotations cannot express, though return format and history behaviour remain undisclosed.

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 short, front-loaded sentences with no filler; the domain is stated first and the caveats follow. It is terse to the point of being telegraphic, which costs a little clarity but wastes nothing.

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 and one required identifier, the description should say what slug denotes and what a caller receives; it conveys the content categories and the no-authority stance but not the identity or history semantics. Adequate as a sketch, incomplete for correct invocation.

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 only 33% - only as_of is documented, while slug (the sole required parameter) and include_history are bare. The description never mentions any parameter, at best implying period handling via 'keep each period explicit', so it does not compensate for the coverage gap and an agent gets no help on what slug identifies or when include_history matters.

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 enumerates the content domain (NPA changes, PCR definitions, capital scope) and the covered institution types (banks/SFBs/UCBs), which is more than a restatement of the name. But it is written as a noun phrase with no verb, so it never states what the tool actually does with that content, and it draws no boundary against close siblings such as bank_npa_reconciliation or rbi_supervisory_tape.

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?

There is no when-to-use guidance and no named alternative; 'keep each period and provisional status explicit' is an instruction about how to present output, not about when to select this tool. The only conditional, 'provisional business updates when accepted', describes data inclusion rather than invocation context, leaving the agent to infer selection from the title alone.

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 readOnly/idempotent/closed-world safety, so the description earns credit for the extra disclosure that results explicitly include stale and missing evidence — a data-quality trait an agent must know to interpret output. The 'not a census or rating' caveat further guards against misusing the result, which is genuine behavioural context beyond structured fields.

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 zero filler, and the scope statement is front-loaded before the disclaimer. The brevity tips into under-specification (unexpanded acronyms) rather than waste, but structurally it is efficient.

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 and only 50% parameter documentation, the description must carry the burden of explaining what a 'coverage' result contains (segments? evidence counts? staleness flags?) and it does not. An agent knows the domain but not what it will receive or how to read sector segmentation.

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 description mentions no parameters at all. Schema coverage is only 50%: as_of is documented, but the sector enum (all/bank/sfb/ucb) has no explanation anywhere, and the description does not compensate by clarifying what these segments mean or how as_of interacts with stale/missing evidence.

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 the resource domain (Bank/SFB/UCB coverage in Indian banking) and clarifies it is 'research, not a census or rating', but it never states a verb or what is actually returned (a coverage report? a list of gaps?). Acronyms SFB and UCB are never expanded, and 'coverage' is doing a lot of unstated work.

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?

'Research, not a census or rating' is a negative exclusion, not guidance on when to call this tool. No sibling is named despite obvious neighbours (evidence_india, institution_research_coverage, evidence_institution), and there is no indication of how this differs from them or when an agent should prefer one.

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, non-destructive, closed-world behavior. The description adds meaningful context beyond annotations: it performs arithmetic reconciliation and does not authenticate inputs, and it requires reduction categories to remain distinct, though it omits rounding and completeness behavior.

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 two tightly packed sentences with no wasted words. The purpose and scope are front-loaded before the important arithmetic-versus-authentication clarification.

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?

The high-level purpose is clear, but for a complex nested reconciliation schema with no output schema, it leaves key behavioral expectations under-specified, including how completeness and rounding affect the reconciliation 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 0% and the single parameter is a complex nested statement object. The description only hints at reduction-category handling ('recoveries/write-offs/sales/upgrades distinct') and does not explain opening/closing values, additions, amount units, rounding, or the complete flag.

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: reconcile supplied NPA movements. It also clarifies that the tool separates reduction categories and performs arithmetic rather than input authentication, which distinguishes its role from validation tools.

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 implies usage when NPA movement data is supplied and explicitly excludes input authentication. However, it does not state prerequisites, when to use it versus the sibling review/evidence tools, or what to do with incomplete data.

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, non-destructive, closed-world behavior. The description adds useful limitations: display-only output, no institution score or tier, and that full=true adds methods. Terms like 'Seiche context' and 'cannot_see preserves gaps' are opaque, but the description still adds meaningful context beyond 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 compact and front-loads the core question and sibling routing. Some fragments such as 'cannot_see preserves gaps' and 'Seiche context never enters regime or transmission' are terse to the point of being cryptic.

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 read-only board with one optional parameter and annotations covering safety, the description is mostly complete. However, without an output schema it does not explain the board's return shape, and unexplained terms ('Seiche', 'cannot_see', 'CP') reduce completeness for an unfamiliar agent.

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 itself explains that full adds method_note, thresholds, and per-leg basis prose. The description's 'full:true adds methods' is consistent but less precise than the schema, so it does not add much semantic value.

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 question and domain: US funding stress transmission to nonfinancial firms. It explicitly distinguishes itself from household_credit_board, so an agent can tell which sibling to use without opening schemas.

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 clear routing guidance for households via household_credit_board and frames usage around one specific question. It does not cover other possible alternatives or exclusions, but the main sibling distinction is explicit.

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/closed-world, so the safety bar is lower. The description adds genuinely new behavioral context: output is "compact" (summarised, not full detail), "details stay on REST" (a scope ceiling), "cited" (provenance is included), and an explicit "display-only, never an institution score or investment advice" framing constraint.

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 verb and resource, then the caveats. Nothing is redundant, though the middle clause chain ("Undertow run-risk cross-read and compound flags") is dense internal jargon that costs a little parse time, and the display-only disclaimer, while worthwhile, is appended rather than integrated.

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 zero-parameter, annotation-covered read with no output schema, the description does the full remaining job: it names the record's fields, states that the payload is cited and compact, and caps expectations by pointing to REST for detail. An agent can call this and set user expectations without any further information.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the schema is trivially covered. Baseline 4 applies; the only concession is that the description does not say the call is argument-free or how the register is scoped (all institutions vs. a default slice).

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 plus a concrete resource ("Read the compact cited bank/crypto exposure register") and enumerates its contents: disclosed quantum, stablecoin/venue links, exposure channels, run-risk cross-read, compound flags. That distinguishes it in substance from siblings like crypto_regime_board or stablecoin_rails_board, but the description never names those siblings explicitly, so the agent still has to infer the boundary.

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?

Usage is only implied: "Read the compact ... register" and "Details stay on REST" tell the agent this is a summary view with depth elsewhere, but it never says when to pick this over crypto_regime_board, stablecoin_rails_board, or failure_radar_board. No prerequisites or exclusions are given, so selection among near-neighbour boards rests on the content list alone.

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, closed-world and non-destructive, so the safety profile is covered; the description adds real context on top: output is a compact board, the bank-exposure cross-read is display-only and does not feed any institution score, and series data must be fetched elsewhere. It stops short of disclosing freshness/cadence for the change-point state, which matters for a regime board.

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?

One front-loaded sentence lists the payload fields, followed by two short constraint clauses — no filler. The field list is dense but every item earns its place given the absence of an output schema; the jargon ('log-SR statistic') is not unpacked, a minor cost.

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 parameters, no output schema and full annotation coverage, the description carries the remaining burden and does so: it enumerates return fields, flags the display-only nature of one of them, and redirects to REST for series. Only the update cadence and whether the board can be empty/undefined 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 schema takes zero parameters, so there is nothing for the description to disambiguate — baseline 4. The description correctly implies a single fixed, unscoped board rather than a filterable query, which sets the right expectation.

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?

A specific verb ('Read') plus a named resource ('compact BTC/ETH Crypto Regime board') and an enumeration of the exact readings it returns: change-point state, log-SR statistic, last shift, observation count, bank-exposure cross-read. It doesn't explicitly name which sibling (crypto_exposure_board, stablecoin_rails_board) to use instead for the neighbouring questions, so it falls short of full sibling differentiation.

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?

Usage is implied rather than stated: 'Time-series paths stay on REST' and 'display-only cross-read' tell the agent what this tool will not give (historical series) and roughly where it belongs, but there is no explicit 'use this when...' or named alternative for the exposure-side question. The 'not investment advice / feeds no institution score' lines are disclaimers, not 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 establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral context beyond that: the tool returns exactly seven cited retrospective files, not an aggregate cohort, and no European recall percentage should be expected.

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 definition is short and front-loaded with the core action and scope. The second sentence usefully rules out cohort-style aggregation, though the 'unrecalibrated Indian lenses' phrasing adds ambiguity rather than cleanly earning 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 one-parameter read tool with rich annotations and no output schema, the description provides enough context to select and call it: scope, cardinality, citation status, and the absence of an aggregate percentage. Greater detail about what a case file contains or what 'unrecalibrated Indian lenses' means would improve completeness.

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 slug parameter is fully documented in the schema, including the example and the instruction to omit it for all seven files. The description does not add further meaning about slug syntax or behavior, so the schema carries the parameter semantics.

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: reading seven cited European retrospective case files. It also distinguishes the resource from a cohort by saying these are named case studies with no European recall percentage. The phrase 'unrecalibrated Indian lenses' is opaque, but the core resource is still identifiable.

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 implies when the tool is appropriate by contrasting named case studies with a cohort and warning that there is no aggregate percentage to quote. However, it does not name alternative sibling tools or explicitly state when to choose evidence_india, evidence_us, or another evidence tool instead.

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, closed-world safety. The description adds substantive domain-specific caveats beyond annotations: publication clocks are preferred, a +60-day filing-lag proxy is used otherwise, and overwritten amendments are unreconstructable. These are exactly the limitations an agent must know before relying on the diagnostic.

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 tightly written sentences, front-loaded with what the tool returns, then methodology caveats, then the sibling distinction. No sentence 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?

For a zero-parameter, read-only diagnostic with no output schema, the description covers scope, data-quality limitations, and the main sibling alternative. It stops short of describing the return structure beyond 'including misses and false alarms', but the core invocation context is 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?

The tool has zero parameters, so parameter semantics are inherently minimal. The description appropriately does not invent parameter discussion; baseline 4 applies for a parameterless 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 ('Read') and a precisely scoped resource: the 48-institution Indian construction-PIT crisis diagnostic. It also distinguishes the deliverable from the sibling 'evidence_institution', which returns a full replay, so an agent can tell the two apart without opening schemas.

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 clearly implies this is the headline diagnostic with misses and false alarms, while 'evidence_institution' provides the full replay. It does not spell out an explicit 'use this when' rule, but the comparative framing gives enough context to choose correctly.

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 and mutability are covered. The description adds useful caveat context that filing-availability proxies do not establish a validated backtest, which helps set expectations for the replay's evidentiary status.

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 compact and front-loads the main action. The three sentences each serve a purpose: core read behavior, sibling routing, and a validity caveat, though the first sentence is dense with domain terminology.

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 single-parameter, read-only diagnostic with no output schema, the description sufficiently explains what the tool returns conceptually: lens alert timing and hit/miss/false-alarm verdict. It also provides a critical caveat about validation, though additional detail on replay contents could further help.

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 slug parameter is already well documented with an example. The description adds value by telling the agent to use evidence_india for exact slugs, clarifying where to obtain valid parameter values.

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: reading a sourced Indian construction-PIT quarterly replay, with focus on alert timing and hit/miss/false-alarm verdict. It distinguishes itself from the sibling evidence_india by directing slug lookup there, though the domain term 'construction-PIT' may not be immediately transparent.

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 clear routing guidance: use evidence_india for exact slugs, implying this tool is for retrieving the replay after a slug is known. It does not explicitly state when not to use the tool or list other alternatives beyond evidence_india.

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), so the description's added value is the data-scope disclosure: India is a 48-institution construction-PIT diagnostic, US is an industry-wide current-amended vintage, and Europe is 'named cases, no cohort claim' — that last phrase is a real caveat about statistical representativeness that structured fields 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?

Two sentences, no filler, and the market-by-market breakdown is front-loaded before the routing instruction. Slightly dense parenthetical packing keeps it off a 5, 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?

For a zero-parameter, read-only hub tool with no output schema and full annotation coverage, the description supplies what an agent needs: what each market's evidence represents, its quality caveats, and where to drill down. Only the shape of the returned summary (counts vs. prose status) is left implicit, which is a minor gap given the tool's simplicity.

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 tool takes zero parameters, so there is nothing about argument semantics to explain and the baseline of 4 applies. The description correctly focuses its limited space on scope and routing instead of inventing parameter guidance.

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 makes clear this is an all-markets overview of historical evidence, enumerating the three markets covered (India, US, Europe) with a qualifier for each. It does not use an explicit verb like 'list' or 'summarize', but the noun-phrase form plus the title leaves no ambiguity about the resource, and the sibling drill-down tools are named so the agent can distinguish this hub from evidence_india/evidence_us/evidence_europe.

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?

'Start here, then evidence_india, evidence_us or evidence_europe for details' gives explicit sequencing and names the alternatives an agent should fall back to. It stops short of stating when to skip this tool (e.g., if the market is already known), but the routing intent is unambiguous.

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 behavior, and the description adds substantive caveats beyond them: amended-vintage data, inclusion of misses, non-validated backtest status, and the fact that this is not an individual-bank verdict. It also names the intended reporting components: watchlist, recall, uncertainty, and lead times.

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 front-loaded sentences with no filler: the core read operation comes first, followed by critical caveats and the expected reporting frame. Dense domain jargon is present, but it is appropriately sized for a specialized diagnostic tool.

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 does a good job naming the key output concepts: quarterly top-decile watchlist, recall, uncertainty, and lead times. It still leaves 'named replays' and the exact return structure somewhat underspecified, so it is strong but not fully 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?

There is one optional boolean parameter, and the schema fully documents it, including its default and the large-payload warning for trajectories. The description adds no additional parameter-specific guidance, so the high schema coverage justifies the 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?

States a specific verb and resource: 'Read US bank current-amended-vintage diagnostics and named replays, including misses.' It distinguishes itself from geographic siblings like evidence_europe/evidence_india and from individual-bank tools by explicitly saying it is 'not an individual-bank verdict.'

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 when-not guidance: 'Not a validated point-in-time backtest' and 'it is not an individual-bank verdict.' However, it does not explicitly route the agent to an alternative sibling tool when those conditions matter, so it falls short of full when/when-not/alternatives 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?

The description adds useful context beyond the read-only annotations: data is 'Vetted,' the output is research rather than a rating, and market_dd has tier-authority requirements. It still does not describe return shape or freshness, but with annotations covering safety and idempotency, this is substantive added context.

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 short, front-loaded with the board's domain, and wastes no words. Its fragmentary style and undefined acronyms make it terse to the point of opacity, but it is not bloated.

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 zero-parameter read-only board, it names the subject matter and one related institution tool, which is enough to attempt invocation. It leaves key domain acronyms unexplained and does not clarify the board's columns, timeliness, or what 'vetted' means in practice.

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?

This tool takes zero parameters, so there is no parameter semantics gap. The description correctly does not invent parameters to explain.

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 domain resource: an India-focused failure radar board covering lender PDs, PCA/SAF, and funding. It also distinguishes itself from failure_radar_institution by noting that it supplies slugs for that tool. The lack of a clear verb and heavy acronym use keep it from 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?

It implies the board is a screening surface whose slugs feed failure_radar_institution, and references market_dd/market_dd_evidence for other workflows. However, it does not explicitly say when to choose this tool over siblings such as rbi_supervisory_tape or evidence_india, nor does it state exclusions for this board.

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, closed-world behavior. The description adds meaningful context by specifying that uncovered institutions return nothing and are never scored from memory, which prevents fabricated answers. It does not mention output format or other operational constraints, but the annotation coverage lowers the burden.

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 three tightly packed sentences. Purpose and contents are front-loaded, followed by the discovery path and the uncovered-institution caveat. No sentence 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?

For a simple one-parameter, read-only tool with rich annotations and full schema coverage, the description is complete. It states what the dossier contains, how to obtain a valid slug, and how uncovered institutions behave, leaving no essential gap for correct invocation.

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 'slug' parameter has 100% schema description coverage, including kebab-case format and provenance from a failure_radar_board row. The description's 'Discover slugs with failure_radar_board' largely repeats what the schema already states, so it adds only marginal value beyond the structured 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 uses a specific verb ('Read') and resource ('one Indian lender dossier') and enumerates the dossier's contents: quarterly PDs and drivers, PCA/SAF headroom, funding, forensic and listed-market evidence. It explicitly distinguishes itself from the sibling failure_radar_board by framing that tool as the discovery mechanism for slugs.

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 gives clear context: use failure_radar_board to discover slugs, then call this tool with one. It also warns that uncovered institutions remain absent and are never scored from memory. However, it does not explicitly compare this tool against the many other evidence/research siblings (e.g., evidence_institution, institution_evidence_monitor) or state when not to use it.

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/non-destructive, so the bar is lower, yet the description adds real behavioral context: odds are suppressed until 60 observed days while counts remain visible, absence is explicitly not precision, and frequencies are not calibrated forecasts. These are exactly the caveats an agent needs to interpret the output correctly.

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?

Four short sentences, front-loaded with what is returned before the caveats. Some phrasing ('absence is never precision') is cryptic jargon rather than plain disclosure, which slightly reduces clarity per word.

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 parameters and no output schema, the description carries the interpretive burden and does so: it says what is returned, when values are withheld, and how to treat them. The only gap is the undefined notion of a 'layer' and the output shape, which a caller must discover by invoking.

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 tool takes zero parameters, and the description does not invent any. Baseline for a parameterless tool applies, with no schema semantics left unexplained.

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 ('Read') and resource ('counted Markov transitions and empirical 5/20-day reach odds'), so the agent knows exactly what data comes back. It does not differentiate itself from the many sibling board/evidence tools or explain what a 'layer' means, which keeps it below 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?

There is no explicit when-to-use vs sibling-tool guidance, but 'Display-only, never a state driver' does constrain how the output may be used. Usage is implied rather than routed to an 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 declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely non-structured behavior: it is display-only, produces no scores or watchlist tiers, reports coverage gaps inside a cannot_see field rather than silently omitting them, and that full:true inflates payload size. It stops short of describing the board's layout or ordering, so not 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?

Four short clauses, front-loaded with the question the tool answers, then the sibling routing, then scope exclusions, then the parameter note. Dense and largely waste-free, though the semi-colon-chained style packs several distinct ideas into run-on fragments that read slightly compressed.

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 board with no output schema, the description supplies what an agent needs: what question it answers, what data families appear, that gaps surface in cannot_see, and that no scoring is produced. Return-shape detail is not required here, but the absence of any note on output sections beyond cannot_see leaves a small gap.

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 parameter is fully documented, so the schema carries the load. The description only adds that full:true brings "methods and histories," a minor extension of the schema's "method_note, thresholds, labels and full sparklines (larger payload)" and a restatement of the payload-size warning. 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 single, specific question the tool answers ("is stress reaching US household credit?") plus the concrete data families it covers (delinquency, charge-offs, revolving credit, debt-service context). It explicitly contrasts with corporate_transmission_board for the firm-side view, so an agent can separate it from siblings 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?

Names the alternative tool and the condition that selects it ("Use corporate_transmission_board for firms"). It also states negative scope — "Display-only; no institution score or watchlist tier" — which routes the agent away from institution-scoring siblings like failure_radar_institution or institution_review_packet.

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 and non-destructive, so the safety profile is covered. The description adds useful context in 'End-of-day as_of' (data freshness) and 'No scoring or delivery authority' (scope boundary), but says nothing about include_history behaviour, result volume or alert semantics.

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?

Four short clauses, front-loaded with purpose and with no filler. The telegraphic style is efficient but borders on cryptic in places (e.g. the bare colon-mapping), which slightly reduces readability.

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 4-parameter read tool with no output schema and no parameter descriptions, the description covers scope and freshness but leaves include_history unexplained and says little about the shape of the returned evidence, gaps and alerts. Adequate but with clear gaps.

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 0%, so the description must carry parameter meaning. It does explain the slug vs slugs vs neither selection and gives as_of an end-of-day interpretation, but the fourth parameter, include_history, is left entirely undocumented in both schema and description.

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 phrase 'Bank/NBFC evidence, gaps and review alerts' names the resource and the three things the tool returns, which is clear enough that an agent knows what it fetches. It does not, however, distinguish itself from near-siblings such as evidence_institution, institution_research_coverage or institution_review_packet, which also deal with institutional evidence.

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?

'slug: one record; slugs: watchlist; neither: all tracked' gives real selection guidance for scope, and 'No scoring or delivery authority' implicitly sets a boundary. But it never states when to prefer this tool over the alternatives or what prerequisites apply, 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a genuinely useful semantic constraint — that appearing in the registry implies no financial coverage or score — but says nothing about result shape, ordering, or what a search returns.

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 short sentences with no filler, and the resource targets are front-loaded before the caveat. It is efficient, though the terseness borders on under-specification for a four-parameter search tool.

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 tool with four undocumented parameters, no output schema, and no annotation-level detail on results, the description is too thin. An agent cannot determine pagination behavior, what 'q' matches, or what a returned row contains.

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 0% for four parameters, so the description carries the full burden. It only implicitly maps 'dossiers or RBI rows' to the scope enum and 'Search' to q, leaving limit and offset (pagination) completely unexplained in both schema and description.

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 verb 'Search' is specific and the description names two target resources ('Indian dossiers', 'RBI rows'), which roughly map to the scope enum. However, 'dossiers' and 'RBI rows' are internal jargon that an agent may not resolve without opening the schema, and it does not clearly distinguish this from siblings like evidence_india or institution_evidence_monitor.

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?

'Overlapping populations; registry presence grants no financial coverage or score' is an interpretive caveat, not usage guidance. It never states when to choose this tool over universe_search, evidence_india, or institution_evidence_monitor, nor any prerequisites or 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 declare readOnly, idempotent, non-destructive and closed-world, and the description goes beyond them with two substantive caveats: stale/dark gaps are retained rather than filled, and the content hash proves non-alteration only, not attestation or publication-time proof. These are real limits an agent would otherwise misread as guarantees.

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 the packet is and how to key it, followed by caveats. Dense domain jargon ('stale/dark gaps', 'attestation') slightly raises interpretation cost but 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 the return artifact, and it does so adequately: a cited packet that preserves gaps and carries a content hash with limited guarantees. What is missing is any sense of packet shape, size, or citation format.

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 parameter is documented as 'exact Failure Radar slug or full institution name'. The description still adds value by clarifying that matching is exact and that a full name must be unique and normalized — behavior the schema does not state.

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 specific resource — a cited human review packet — and pins the retrieval key to an exact slug or unique normalized full name. The verb is implicit (packet is a noun phrase), and it never names a sibling such as evidence_institution or failure_radar_institution, so differentiation is left to inference.

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?

'No fuzzy match or new score' tells the agent what this tool will not do, which implicitly routes fuzzy lookups and scoring elsewhere. However, no alternative sibling is named and there is no positive statement of when this packet is the right choice over evidence_institution or institution_research_coverage.

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 bar is lower, and the description still adds real behavioral content: the return may be either live analysis or a 'labelled historical replay', it carries an evidence clock and a passing publication receipt, and facts are not regenerated. That dual-mode disclosure is exactly the kind of trait 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?

Two sentences with no filler, and the core resource ('today's exact full-text editorial') is front-loaded. Some phrasing is dense internal jargon ('evidence clock', 'passing publication receipt') that costs a little immediate clarity.

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 parameters and no output schema, the description carries the burden of explaining what comes back, and it does: full text, evidence clock, publication receipt, plus the current-vs-replay distinction. Only minor gaps remain, such as what 'today' means across timezones or whether the call can fail.

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?

Zero parameters, so the baseline of 4 applies; the description correctly implies a no-argument call. There is nothing further the description could add about inputs.

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 ('Read') plus a specific resource ('today's exact full-text LiquiLens editorial') with scope clarified as current analysis or a labelled historical replay. It is distinguishable from sibling evidence_* and verify_published_record tools by being the editorial artifact itself, though it never names a sibling to contrast with.

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?

Usage is implied rather than stated: the agent learns it should call this to obtain today's article and quote it with its evidence clock and publication receipt. There is no explicit 'use this instead of X when Y', and the closest alternative, verify_published_record, is never referenced.

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 the safety profile is covered. The description adds real value beyond them: result ordering (newest first), per-item inclusion of the RBI source URL, and an explicit empty-result contract ('A missing snapshot is stated, never returned as silent emptiness'), which prevents an agent from misreading emptiness as 'no enforcement actions exist'. It does not disclose snapshot freshness/staleness or volume, hence not 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, zero waste. Scope and content types come first, then the empty-state guarantee — both front-loaded and each sentence carrying distinct 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?

For a zero-parameter, read-only list tool with no output schema, the description covers what is returned (action types, source URL per item, newest-first order) and the failure/empty case, which is the main ambiguity. Minor gap: no indication of how many items to expect, how 'latest' is bounded (time window), or snapshot freshness, which would matter for an agent judging currency.

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 tool takes zero parameters, so the documented baseline of 4 applies; there are no arguments whose semantics need explaining. The description correctly spends no words on parameters and instead covers scope and output shape.

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 specific verb ('Read'), a specific resource ('latest RBI enforcement and supervisory actions'), enumerates what counts (penalties, licence cancellations, directions), and pins the source ('rbi.org.in press releases'). An agent can distinguish it from generic siblings like latest_article or evidence_india, though no sibling is named explicitly.

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?

Usage is implied by 'latest ... newest first' — this is the tool for current supervisory/enforcement news rather than historical or cross-domain evidence. However, there is no explicit when-to-use statement, no exclusions, and no pointer to the sibling an agent should pick instead for related needs (e.g. verify_published_record, evidence_india).

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, non-destructive, closed-world behavior, so the bar is lower. The description does add real context beyond them: default responses return truncated metadata unless limit is raised, and the call has no side effects on identity, scores, or eligibility while retaining rights. It still omits pagination behavior for offset and what a result record contains.

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 tight sentences with no padding, but the brevity is achieved through opaque proper nouns rather than compressed clarity, so density does not translate into information for the caller.

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, three undocumented parameters, and a nine-value topic enum, the description should explain what comes back and how topic/offset behave. Instead it leaves the agent guessing about the result shape and pagination semantics.

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 0%, so the description must carry parameter meaning. It only hints at 'limit' controlling metadata completeness; topic (a 9-value enum) and offset are entirely unexplained, and it never clarifies whether limit counts records or metadata 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 verb 'route to' is vague and the resources are four internal codenames (Palimpsest, Seiche, Undertow, NarcoScope) that an agent cannot map to a concrete operation. Nothing distinguishes it from siblings like universe_search, evidence_markets, or institution_research_coverage.

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?

There is no statement of when to use this tool versus the many evidence_*/research_* siblings, no prerequisites, and no exclusions. The only actionable phrasing ('Set limit for full metadata') is a parameter note, not usage 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 and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: partial data is never reported as CALM, pagination continues via a next_offset field, and full receipts are only on REST. 'Display-only, not investment advice' also sets expectations on output nature.

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?

Four short clauses, front-loaded with the resource and no filler. The compressed fragment style is efficient, though terms like CALM and receipts are used before being defined.

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, naming the pagination.next_offset field is valuable, but key vocabulary (CALM, peg/run, receipts) is undefined and neither parameter is described. Adequate for a simple two-parameter read board, but not sufficient for an agent to fully interpret results.

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 0% for both limit and offset, so the description has to carry the burden. It only gestures at paging via next_offset and never explains limit's max of 8, offset semantics, or default page size, leaving the actual invocation details undocumented.

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 the resource concretely as 'paged peg/run evidence', which clearly marks this as the stablecoin peg/run board rather than the crypto exposure or regime boards among its siblings. The verb is implicit (it is a read board) and the term 'CALM' is left undefined, but an agent can tell what it retrieves.

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?

'Follow pagination.next_offset' and 'Full receipts on REST' give operational direction and hint that REST is the route for full detail. There is no explicit when-to-use or when-not versus the many adjacent board tools (crypto_exposure_board, failure_radar_board, etc.), so routing must be inferred from the domain wording.

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 a genuinely useful domain caveat, "Registration does not establish creditworthiness," that guards against over-reading results; pagination/row behavior is only implied by the limit parameter.

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, zero filler, with the search scope front-loaded before the invocation rule and the 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?

No output schema exists, so the agent must infer the return shape, but the limit parameter and "maximum rows to return" make that clear enough. With annotations covering safety and full schema coverage, the description leaves little an agent needs 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%, so the baseline is 3, but the description earns above baseline by explaining how parameters combine — q alone, filter alone as a slice browse — which the schema does not state. It does not clarify whether q plus a filter intersects or which wins.

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 ("Search the RBI NBFC register") plus the exact search dimensions (name/CIN substring, classification, regulation layer). No sibling tool covers this register, so no disambiguation is needed, but the scope is unambiguous on its own.

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?

"Supply q or a filter; a filter without q browses that slice" gives concrete invocation patterns and explains the browse-vs-search modes. It does not name when-not-to-use cases or alternatives, 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/closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing that verification recomputes hash chains (implying compute cost) and that it "returns the actual verifier verdict, including failures" — i.e. failures are surfaced, not swallowed. It stops short of stating latency, cost, or what happens when signatures/anchors are disabled.

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, zero filler, with the mechanism stated first and the scope caveat last. Every clause earns its place by either defining the operation or bounding its interpretation.

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, annotation-rich tool with no output schema, the description covers what is checked, that failures are reported honestly, and what class of answer is out of scope. The remaining gap is the shape of the verdict (fields, pass/fail granularity per signature or anchor), which an agent would have to discover by calling 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?

With one parameter and 100% schema coverage including a default, the schema already carries the meaning; the description only echoes "ledger stream." It adds no detail on valid stream names, whether the default stream is the common case, or what an unknown stream does — 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?

"Verify a ledger stream by recomputing hash-chain commitments and checking enabled signatures and anchors" names a specific verb, a specific resource, and the exact mechanism used. The closing clause "Verifies record integrity, not economic accuracy" separates it cleanly from the economic and board-style siblings in the same namespace.

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 boundary "record integrity, not economic accuracy" gives a genuine when-not signal that steers agents away from using this for analysis questions. However, no sibling is named as the alternative for the economic side, so the agent must still infer routing from the wider tool list.

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