LiquiLens — the Failure Radar

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

Annotations already declare readOnlyHint=true and idempotentHint=true; the description reinforces this by starting with 'Read' and adds useful behavioral context: the review is free, produces no new score, and carries no credit approval or execution authority. It also clarifies the scope of data covered, going beyond the bare 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 reasonably concise and front-loaded with the core action and resource, followed by specific data elements and limitations. Every sentence adds meaningful information, though the second sentence is list-like and could be slightly tighter.

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

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

For a read-only review tool with no output schema, the description provides a solid overview of inputs and scope, plus important limitations. However, it does not describe the return shape or what an agent should expect from the output, and parameter semantics are incomplete, leaving some practical invocation details to inference.

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 only 33%, and the description does little to compensate. It never explains how to construct the required slug, what as_of cutoff implies beyond the schema already stating it, or what include_history=true actually changes in the output. The mention of 'history' hints at include_history but is not explicit, leaving parameter semantics under-specified.

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 clearly identifies the resource (a bank's GNPA/NNPA asset-quality history) and the specific action ('Read'), with concrete components such as percentage-point changes, PCR definitions, capital scope, and NPA stock reconciliation. It is not a tautology and conveys the tool's focus, though it does not explicitly differentiate it from the sibling bank_npa_reconciliation.

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 use when a bank's asset-quality history or SFB/UCB review context is needed, and notes that no credit approval or execution authority is granted. However, it does not explicitly state when to prefer this tool over alternatives such as bank_npa_reconciliation or institution_review_packet, so usage guidance is mostly implied rather than directly actionable.

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 mark readOnlyHint and idempotentHint, and the description adds useful behavioral detail by explaining that output separates observed, stale, historical, and absent evidence. It also sets expectations as research rather than a rating. No contradiction with 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 brief, information-dense sentences. The first sentence states the core purpose, the second explains the output taxonomy, and the third sets boundaries. No redundant 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?

For a read-only coverage lookup with two optional parameters and no required inputs, the description sufficiently conveys what the tool does, its scope, its evidence categories, and its limitations. It does not describe the exact result shape, but the evidence taxonomy is clearly implied.

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 documents as_of and provides enum values for sector. The description indirectly explains sector values by naming commercial, small finance, and urban cooperative banks, but it does not explicitly map enum labels to those categories or explain how as_of affects coverage. With 50% schema coverage, the description only partially compensates.

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 ('Discover') and resource ('covered Indian commercial, small finance and urban cooperative banks'), and clearly distinguishes the tool from broader evidence or rating tools by adding 'Separates observed, stale, historical and absent evidence' and 'this is not a census or rating.'

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 context: free read-only research, coverage-focused, and explicitly says what it is not ('not a census or rating'). However, it does not name sibling alternatives or state when to choose this over tools like evidence_india or universe_search, so it stops short of fully explicit routing.

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

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

Annotations already provide readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: it keeps write-offs, sales, upgrades and cash recoveries distinct, and it performs no authentication or classification.

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 carry the entire meaning with no wasted words. The primary behavior is front-loaded, followed by the key limitations. It does not repeat schema content or annotation content.

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 description covers the core reconciliation logic and limitations well, which is essential for a nested-input tool. However, with no output schema, it never states what the tool returns, and it leaves some nested parameter behaviors implicit, such as how `complete` or `rounding_decimals` affect the check.

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 compensate for the single nested `statement` parameter. It explains that the statement is a closed NPA movement table and connects the arithmetic fields, but it does not add meaning for nested fields like `complete`, `amount_unit`, or `rounding_decimals`.

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 ('Reconcile') and resource ('caller-supplied closed NPA movement table'), then defines the exact arithmetic identity being checked. It also separates itself from loan classification and authentication, making its purpose unmistakable.

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 use case is explicit: reconcile a disclosed NPA movement statement arithmetically. It also gives clear when-not guidance by stating it does not authenticate input or classify individual loans, so the agent knows not to use it for those tasks.

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?

Beyond the readOnly/idempotent hints, the description adds meaningful behavioral disclosure: it is display-only, does not produce an institution score or tier, preserves unknown data as cannot_see, and states that Seiche context never enters regime/transmission. These are concrete limitations and edge-case behaviors an agent could not infer from the annotations alone.

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, front-loaded with the core purpose, and every sentence earns its place by adding scope, boundary, or behavior. It avoids redundant restatement of the title or schema.

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 board tool with one optional parameter, no output schema, and readOnly/idempotent annotations, the description is complete enough to invoke correctly. It covers what the board answers, what is excluded, how missing data is handled, and the only parameter's effect.

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 already documents the single full parameter with 100% coverage, so the baseline is 3. The description mentions 'full:true adds methods,' but the schema description is actually more specific about what full returns. Thus the description adds minimal new parameter meaning, and the schema carries the burden.

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 precise question ('is US funding stress reaching nonfinancial firms?'), identifies the content areas (CP, bank credit lines, real-economy confirmation), and explicitly distinguishes this board from household_credit_board. It also clarifies what it is not ('Display-only; no institution score or tier'), leaving no ambiguity about the resource's scope.

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 explicitly names the alternative for households ('Use household_credit_board for households') and scopes this tool to nonfinancial-firm funding stress. It also gives parameter-usage guidance ('full:true adds methods') and reinforces the tool's single-purpose nature with 'Answers ONE question'.

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, and openWorldHint=false. The description adds meaningful behavior beyond that: it is 'display-only,' 'never an institution score or investment advice,' and returns only compact/cited data, with detailed disclosures intentionally left to the REST detail route. No contradictions with 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-loaded with the core action and resource, followed by a useful pointer to the detail route and a caveat. Every sentence adds value, though the dense cluster of domain jargon ('Undertow run-risk cross-read and compound flags') makes it slightly less immediately digestible.

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 no-argument, read-only board, the description covers what the tool returns, its compact nature, and where fuller details live. There is no output schema, so the enumerated content fields help close that gap. It does not describe the exact response format, but this is a low-complexity display tool and the caveats plus annotations provide adequate context.

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 and the input schema already documents this fully (empty properties, additionalProperties=false). The description redundantly notes 'Takes no arguments,' which is harmless, and there are no parameter 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?

The description names a specific verb and resource: 'read the compact cited bank/crypto exposure register,' and enumerates the register's contents (quantum, stablecoin and venue links, exposure channels, Undertow run-risk cross-read, compound flags). It is clearly a read-only board tool, but it does not explicitly contrast itself with closely related siblings like crypto_regime_board or stablecoin_rails_board.

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 to use the tool: for the compact register, while 'detailed disclosures stay on the public REST detail route' signals where to go for more depth. It does not discuss sibling alternatives or give explicit when-to-use/when-not-to-use guidance relative to other boards.

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 and idempotentHint, and the description reinforces this with 'Read', 'display-only', and 'feeds no institution score'. It adds context about the board's scope and limitations, including the time-series route clarification, without contradicting the 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 sentences, each earning its place: the first states the core purpose and contents, the second clarifies where time-series data lives, and the third covers invocation and scope limitations. It is front-loaded and free of 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?

For a zero-parameter read-only tool, the description is complete: it lists the returned board contents, clarifies the display-only cross-read, states the non-institution-score scope, and points to the public REST detail route for time-series. No output schema exists, but the description supplies the necessary return-value context.

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 are zero parameters, so the schema provides full coverage. The description explicitly states 'Takes no arguments', removing any ambiguity about invocation. This is the appropriate baseline for a no-parameter 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?

The description names the specific verb 'Read' and the resource 'BTC/ETH Crypto Regime board', then enumerates its contents: change-point state, log-SR statistic, last shift, observation count, and the cross-read against disclosed bank exposure. It also distinguishes itself by noting it feeds no institution score and is display-only, setting it apart from sibling boards.

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: it takes no arguments, is display-only, feeds no institution score, and is not investment advice. It also directs time-series needs to the public REST detail route. It does not explicitly name a sibling alternative, but the when-not-to-use signals are strong enough for an agent to route 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 cover readOnlyHint and idempotentHint; the description goes beyond them by disclosing the retrospective, named-case perspective, the 'seven' file scope, and the caveat that no cohort recall percentage should be quoted. It also specifies the two behavioral modes (summary vs full case file) without contradicting the read-only annotation.

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, front-loaded with the tool's purpose before usage instructions, with no redundant filler. The phrase 'through unrecalibrated Indian lenses' is compact but somewhat opaque, slightly reducing immediate comprehensibility for an agent.

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-optional-parameter read tool with strong annotations, this is nearly complete: it defines both call modes and the key methodological caveat. The lack of an output schema means the return shape is only described at a high level (summaries vs full quarterly case file), and 'unrecalibrated Indian lenses' is left unexplained, but an agent can still invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents the optional slug; the description adds the key semantic distinction that omitting the slug yields summaries while supplying a returned slug yields a full quarterly case file. The phrase 'returned slug' adds implicit provenance beyond the schema's generic optional-string description, though it could be clearer about whether any valid slug is accepted.

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?

Opens with a specific verb+resource: 'Read seven cited European retrospective case files,' naming the geographic scope and file type. The second sentence reinforces the distinction from cohort-style siblings ('Named case studies, not a cohort'), so an agent can distinguish it from evidence_us/evidence_india and aggregate 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?

Gives concrete invocation guidance: omit slug for summaries, supply a returned slug for a full quarterly case file. It states a clear when-not ('no European recall percentage to quote') but does not explicitly name alternative tools or conditions for choosing them, relying on sibling names and domain to make the selection clear.

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 mark the tool read-only and idempotent, and the description adds non-obvious behavioral details: publication-clock handling, the +60-day filing-lag proxy, and the unreconstructability of overwritten amendments. These caveats materially shape what the agent can expect from the returned 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 sentences carry distinct value: function and content, data-lag caveat, and sibling routing. The description is front-loaded with the core purpose and contains 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?

For a parameterless read-only tool, the description explains what is returned, the main data caveats, and where to get a fuller replay. It could be more explicit about the output format, but the given details are sufficient for an agent to invoke and interpret the 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?

The input schema is empty with no parameters, so the description need not explain parameter semantics. Per the rubric, zero parameters warrants a baseline of 4, and no additional parameter information is missing.

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 (the 48-institution Indian construction-PIT crisis diagnostic), states the verb 'read', and lists included content (misses and false alarms). It also distinguishes itself from evidence_institution by noting that sibling returns a full replay.

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 context for when this tool is appropriate by scoping it to the India construction-PIT diagnostic and directs users to evidence_institution for a full replay. It does not explicitly state when not to use this tool versus the other regional evidence tools, but the contrast with evidence_institution provides clear routing.

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

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

With readOnlyHint, idempotentHint, and openWorldHint already covering the safety profile, the description adds meaningful context beyond annotations: the content is sourced, the lens is alert timing with hit/miss/false-alarm verdicts, and proxy data does not count as a validated backtest. No annotation contradiction exists.

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 sentences, each carrying distinct information: what the tool does, where to find valid slugs, and a caveat. Front-loaded with the action and resource before any caveat.

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 tool with no output schema, the description explains the input resolution path and the nature of the output (alert timing and verdicts). It is slightly opaque about the meaning of 'construction-PIT' and the exact output shape, but the low complexity makes this a minor 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 slug property already includes format and examples. The description adds extra value by directing the agent to evidence_india for exact slugs, which is a practical resolution hint for the only parameter.

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 ('a sourced Indian construction-PIT quarterly replay'), and the diagnostic output ('alert timing and hit/miss/false-alarm verdict'). It also distinguishes itself from the sibling evidence_india by pointing to that tool for slug lookup.

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 tells the agent to use evidence_india for exact slugs, thereby routing slug discovery to the right sibling. It also warns that filing-availability proxies do not establish a validated backtest, giving an implicit when-not condition.

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 and idempotent behavior, so the bar is lower. The description adds meaningful context by clarifying the tool returns per-market headlines, that Europe is 'deliberately no cohort claim,' and that the tool takes no arguments. It does not describe the exact response shape, but that is a minor gap for a read-only, zero-argument tool.

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 sentences with no filler: the first front-loads the action and scope, the second handles arguments, and the third provides routing guidance. Every sentence contributes 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-argument read-only tool with no output schema, the description is complete. It covers what the headline summarizes, market-specific nuances, and how to obtain the full record through sibling tools. An agent has all the information needed to select and invoke it 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?

The tool has zero parameters and the schema already documents this fully. The description reinforces it with 'Takes no arguments,' which is sufficient. Per the rubric, a zero-parameter tool receives a baseline of 4.

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 opens with a specific verb and object: 'Read the historical-evidence headline for each market' and then enumerates the three markets with their distinct diagnostics. It explicitly differentiates itself from sibling drill-down tools by positioning evidence_markets as the market-level summary.

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 an explicit usage rule: 'Start here when asked what LiquiLens has tested, then drill into evidence_india, evidence_us or evidence_europe for the full record behind each headline.' This tells an agent when to choose this tool and which siblings to use next, satisfying the when/alternatives requirement.

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 behavior. The description adds valuable behavioral context: it is a diagnostic report, not a validated backtest, not bank-specific, and it reports aggregate quarterly watchlists with recall, uncertainty, and lead times. This goes beyond the annotation surface without contradicting it.

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-loaded with the core purpose. The caveats and output summary are packed into three sentences that all earn their place, though the density of caveats and output details makes it slightly less skimmable than it could be.

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 one optional boolean parameter and no output schema, the description covers what is returned (quarterly watchlist, recall, uncertainty, lead times), the scope (US construction-PIT), and the parameter behavior. It is sufficient for correct selection and invocation, though it could briefly name sibling evidence tools for routing.

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 optional parameter is fully documented in the schema with its default and payload-size warning. The description's 'include_trajectories:true adds histories' restates the schema concept in plainer language but does not add materially new semantic information beyond it.

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 ('Read') and a specific resource ('US bank current-amended-vintage diagnostics and named replays, including misses'). It also clarifies what the tool is not ('Not a validated point-in-time backtest') and that it is not an individual-bank verdict, distinguishing it from related monitoring 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?

The description gives clear when-to-use context for US construction-PIT watchlist diagnostics and explicitly excludes use as a validated backtest or an individual-bank verdict. However, it does not name sibling alternatives or state conditions for choosing them, 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?

The description adds meaningful behavior beyond the readOnlyHint and idempotentHint annotations by disclosing that scalar market_dd requires tier authority while display-only DD retains clocks and refusal reasons in market_dd_evidence. It also adds the caveat that this is a research screen, not a credit rating.

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 dense sentences with no filler: the first fronts the core resource and content, the second adds the access nuance, and the third gives routing and intended-use context. Every sentence earns 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 zero-parameter read-only board, the description is complete enough: it states what the board contains, flags the authorization constraint, and tells the agent what to do next. Although there is no output schema, the data categories are enumerated sufficiently for an agent to invoke and interpret the tool.

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

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

The tool has zero parameters and the schema coverage is 100%, so the baseline applies. There are no parameter details for the description to add, and it correctly avoids inventing any.

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 a specific resource ('fresh-vetted Indian lender rows') and enumerates the content areas: failure PDs, disclosure, PCA/SAF, funding, and listed-name DD. It also differentiates the tool from failure_radar_institution by positioning this as the slug-discovery board.

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 provides a clear workflow cue: discover slugs here, then use failure_radar_institution. It also frames the tool as a research screen rather than a credit rating. It does not explicitly contrast this with every sibling board, but the Indian lender scope and downstream routing give sufficient usage context.

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?

Beyond the readOnlyHint, the description explicitly states that uncovered institutions 'remain absent, never scored from memory,' which is a crucial closed-world behavioral disclosure that prevents hallucination. It also names the data categories returned, adding valuable context not present in annotations alone.

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 with no filler. The action and content are front-loaded, and the behavioral caveat is placed at the end without bloating the description.

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 tool with strong annotations, the description covers what data is returned, how to obtain a valid slug, and what happens for uncovered institutions. No output schema exists, but the enumerated content types give the agent sufficient expectation of the response.

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 already thoroughly documents the single parameter with format, source, and example. The description adds meaning by tying the slug to failure_radar_board discovery and by implying that only covered institutions are valid inputs, which goes beyond the schema's basic type/format explanation.

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 opens with a specific verb+resource ('Read one Indian lender dossier') and enumerates the substantive contents: quarterly PDs and drivers, PCA/SAF headroom, funding, forensic and listed-market evidence. It also references the sibling failure_radar_board for slug discovery, which helps situate the tool among its siblings.

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 this tool to read a dossier for a single covered Indian lender, and discover valid slugs via failure_radar_board. It also warns that uncovered institutions are absent, effectively telling the agent not to attempt lookup for unknown institutions, though it does not explicitly enumerate alternatives or when-not conditions.

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?

Beyond the readOnlyHint, idempotentHint, and openWorldHint annotations, the description adds substantive behavioral detail: odds are withheld until 60 observed days, counts remain visible, absence is not to be read as precision, and values are not calibrated forecasts. This goes well beyond what the annotations alone 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?

Three sentences, each earning its place: the first states the resource, the second describes data availability semantics, and the third adds critical interpretation caveats. It is compact, front-loaded, and contains 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?

For a no-argument read-only tool, the description covers purpose, availability thresholds, absence semantics, and forecasting limitations. It does not spell out the exact response shape, but there is no output schema and the core return concept is clear from 'counts' and 'odds'.

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 input schema has zero parameters and 100% coverage trivially, so parameter-level documentation is unnecessary. The description supplies the needed context about what is read and how missing values behave, matching the baseline 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?

The description opens with the specific verb 'Read' and names the exact resource: counted Markov transitions and empirical 5/20-day reach odds. This aligns with the title and is clearly distinguishable from the board/review-style sibling tools, none of which cover the same raw Markov odds output.

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 phrase 'Display-only, never a state driver' gives an explicit when-not-to-use boundary, and 'Historical frequencies are not calibrated forecasts' warns against using the output as a forecast. It does not explicitly name an alternative tool, but there is no close sibling doing the same thing, so the guidance is still clear enough.

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?

Beyond the readOnly and idempotent annotations, it discloses that output is display-only, excludes institution-level scores and watchlist tiers, and that data gaps remain flagged as cannot_see. It also explains the effect of full:true on the payload, adding behavioral detail without contradicting 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-loaded: core question first, sibling routing second, limitations third, and parameter effect last. Every sentence earns its place and there is 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?

For a simple display-only board with one optional boolean, the description covers what question it answers, what data themes it includes, what it excludes, how gaps are represented, and the optional parameter's effect. Nothing needed to invoke it 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?

The single parameter full is already fully documented in the schema with default behavior and payload implications. The description adds the useful nuance that full:true also returns methods and histories, which is extra value beyond the schema, though not strictly necessary given 100% schema coverage.

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 the exact question answered ('is stress reaching US household credit?'), names the resource (US household credit), and explicitly differentiates it from corporate_transmission_board for firms. This gives a specific, scoped purpose an agent can distinguish from siblings without inspecting 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 explicitly directs agents to corporate_transmission_board when the focus is firms, and clarifies this board is display-only with no institution score or watchlist tier. This provides clear when-to-use and when-not-to-use guidance relative to 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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses that the packet preserves stale/dark gaps and validation hashes, that its content hash detects alteration, and that it is not attestation or publication-time proof. This is exactly the kind of caveat an agent needs.

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 dense sentences, each earning its place: purpose/front-loaded, input constraint, and behavioral caveat. No fluff or repetition.

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 one parameter and no output schema, the description still tells the agent what the packet contains (citations, gaps, hashes), what it is not, and how its integrity is verified. 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% for the single institution parameter, and the description adds real constraints: 'Exact slug or uniquely normalized full name only; no fuzzy matching or new score.' This goes beyond the schema's 'exact Failure Radar slug or full institution name' by defining uniqueness and exclusion.

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 opens with a specific verb and resource: 'Build a compact cited human review packet from canonical fresh-vetted Indian radar records.' It also distinguishes itself from siblings via 'no fuzzy matching or new score' and the exact-slug constraint, which separates it from search/evidence 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?

The description gives clear operational guidance for when the tool is appropriate: exact slug or uniquely normalized full name only, no fuzzy matching or new score. It does not explicitly name sibling alternatives or list when-not-to-use, but the Indian-radar-records scope provides clear context.

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 mark readOnlyHint and idempotentHint true, and the description adds meaningful behavioral details: the tool returns the exact full-text, labels historical replays, and provides an evidence clock and passing publication receipt. It also tells the agent it can quote the article without regenerating facts, which is useful operational guidance beyond the annotations.

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

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

Two tightly packed sentences with no filler. The action and resource are front-loaded, and every clause adds value: current vs replay behavior, return contents, and usage guidance for quoting.

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 tool with no output schema, the description is complete: it explains what is returned, when a historical replay occurs, and how the result should be used. An agent has all necessary context to call and interpret the tool 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?

The tool has zero parameters, so there is no parameter semantics to document. The description compensates by enumerating the return contents (headline, dek, Markdown, evidence clock, receipt), which gives the agent a clear picture of what invoking the tool will produce.

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 ('Read') and resource ('today's exact full-text LiquiLens editorial'), and differentiates between current analysis and labelled historical replay. It clearly distinguishes this tool from the sibling evidence and board tools by focusing on the canonical editorial artifact.

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 to use it: to read the current editorial or a historical replay depending on whether the evidence moved. It does not explicitly name alternative tools or exclusion conditions, but the context is clear enough for an agent to select this tool over the sibling analysis reports.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses meaningful behavior: results are newest first, each item carries the RBI's source URL, no arguments are accepted, and an empty or missing snapshot produces a stated note rather than silence. This goes beyond what annotations alone provide.

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 sentences, front-loaded with the core purpose, then the no-argument fact, and finally the edge-case behavior. Every sentence contributes unique information and there is no redundant 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?

For a parameterless read-only list tool, the description covers what is read, source, ordering, URL inclusion, and the empty-snapshot behavior. No output schema exists, but the description gives enough context for an agent to invoke the tool and interpret the response at a high level.

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 are zero parameters and the schema already documents this with 100% coverage. The description reinforces this by explicitly stating 'Takes no arguments', which is useful even though the schema is clear. Baseline 4 is appropriate for a no-argument 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?

The description states a specific action ('Read'), a specific resource ('latest RBI enforcement and supervisory actions'), and enumerates content types (monetary penalties, licence cancellations, supervisory directions) plus source and order. This clearly differentiates the tool from the sibling tools by domain and function.

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 tool's purpose and scope clear, including that it takes no arguments and that it handles a missing snapshot explicitly. It does not name alternatives or state when not to use this tool versus siblings, but the context is sufficiently 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 declare this read-only/idempotent, and the description adds meaningful behavior: compact output by default, full metadata when 'limit' is raised, no identifier/score/eligibility changes, and source rights staying attached. This goes beyond the annotations and helps an agent understand outputs and non-effects.

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-loaded, with no filler. The first sentence states the core purpose and the second statement adds key behavioral constraints. It is slightly dense with proprietary names, but every clause earns 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?

Given there is no output schema and no parameter-level help, the description is only partially complete. It clarifies output verbosity and safety, but it does not explain the offset pagination parameter, the exact meaning of 'full metadata', or how the topic enum maps to the listed data sources. It is adequate for a simple read-only call, but leaves meaningful 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 compensate, but it only explains the limit parameter ('set limit for full metadata'). The topic parameter is only indirectly alluded to via the named data sources, and offset is completely unexplained. Two of three parameters remain under-specified.

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 action—connecting institution research to multiple named data sources (Palimpsest, Seiche, Undertow, NarcoScope)—which gives the tool a clear core purpose. However, 'connect' is somewhat abstract and it does not explicitly distinguish this tool from the sibling evidence_* and institution-focused tools nearby.

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 to use it: when institution research needs to be linked with source, funding, liquidity, or global data context. It also gives a partial exclusionary note ('No institution identifiers, scores or eligibility changes'), but it never names alternative tools or clearly states when to choose a sibling 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 establish read-only, idempotent, and closed-world behavior. The description adds meaningful behavioral caveats beyond those annotations: the board never treats partial evidence as CALM, a separate alert is retained for compatibility, and the board is not investment advice. These are important nuances an agent could not infer from the schema or annotations alone.

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 packs a lot of domain detail into three sentences and is appropriately front-loaded with the core action. Every clause adds useful information, though the dense enumeration of board contents makes it slightly heavy.

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 explaining what the board contains, and it does so by listing issuer-level evidence, chain concentration, tripwire state, and the aggregate regime. It also redirects users needing detailed series or full receipts to the REST route, providing reasonable completion for an agent deciding whether to invoke this tool.

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

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

The tool has zero parameters, and the schema already shows an empty property set. The description confirms this with 'Takes no arguments', matching the 0-params baseline of 4; there is no additional parameter semantics to provide.

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 opens with a specific verb and resource: 'Read the compact Stablecoin Rails board', then enumerates the board's contents in detail. It is clear what the tool does, though it does not explicitly name or contrast sibling tools, so it stops 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?

It states that series and full receipts live on the public REST detail route, which tells the agent not to expect those here. It also mentions the separate peg/run alert and explicitly notes the tool takes no arguments, giving useful usage context even though no sibling tool is named.

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 and idempotent, so the description needn't restate them; it adds useful behavior: substring matching, filter-only browsing, and a disclaiming caveat. It accurately aligns with idempotentHint=true.

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-loaded: the operation and target come first, then the parameter-use rule, then the caveat. Every sentence earns its place without redundancy.

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

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

For a read-only search tool with four optional, fully documented parameters, the description covers what the tool does, how arguments combine, and what it returns. Without an output schema, a bit more detail on row contents would be nice, but it is still invocable correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds extra semantic value by mapping the search dimensions to q, classification, and layer, and by explaining the q-or-filter browsing behavior. It doesn't provide new syntax details, but the schema already handles that.

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

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

The description clearly identifies a specific verb ('Search'), resource ('RBI NBFC register'), and the match criteria (name/CIN substring, classification, layer). It distinguishes itself from sibling tools by focusing on the official register, though it does not explicitly name any alternative.

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 practical guidance: either q or a filter can be supplied, and a filter alone browses that slice, plus a caveat that registration doesn't imply creditworthiness. However, it doesn't describe when to choose this tool over sibling tools or 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 indicate read-only and idempotent behavior. The description adds meaningful behavioral detail beyond those: it recomputes hash-chain commitments, checks enabled signatures and anchors, and returns the actual verifier verdict including failures. This gives the agent a realistic picture of what happens without undermining the readOnlyHint.

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 packed sentences, each earning its place: the first states the action and mechanism, the second clarifies return behavior, and the third states a critical limitation. There is no fluff or redundant restatement of the title.

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 one optional parameter and no output schema, the description is complete. It explains what is verified, how, what is returned, and what is explicitly out of scope. An agent has enough context to decide when to invoke it and what to expect in the response.

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 describes the only parameter, 'stream', with 100% coverage including a default value. The description reinforces 'ledger stream' but does not add new semantic detail beyond the schema. Baseline 3 applies because the schema carries the parameter documentation.

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 opens with a specific verb and resource: 'Verify a ledger stream'. It then explains the method ('recomputing hash-chain commitments and checking enabled signatures and anchors') and clearly distinguishes its scope ('not economic accuracy'), making the tool's purpose unambiguous and distinct from any sibling 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?

The description gives clear context: use this to verify record integrity via ledger stream verification. It also provides a notable exclusion with 'not economic accuracy', which helps an agent avoid using it for economic validation. No alternative tools are named, but no sibling appears directly similar, so the guidance is sufficient though not exhaustive.

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