distress-abc

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

No annotations provided, so description carries full burden. It discloses a multi-hop parse, hand-verifiable nature, cost of $0.50 USDC, and data sources (UCC, county records). Warns to verify before acting, adding transparency beyond basic 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 front-loaded with purpose but contains redundant phrasing (e.g., 'the map the assignee needs... and the map a buyer needs') and unnecessary details (payment note). It could be more concise while retaining key points.

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 no output schema, the description adequately explains the return (collateral inventory and buyer actions per role), data sources, and verification requirement. Missing details on output format and exact roles, but sufficient for an agent to grasp the tool's function.

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 baseline is 3. Description adds value by explaining link and entity usage (prefer link, override with entity), but does not elaborate on the 'state' parameter beyond schema. This provides minimal added meaning.

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 states the tool builds a 'full WIND-DOWN ASSET / COLLATERAL MAP' for an ABC case, specifying the verb (build) and resource (map). It distinguishes from siblings like abc_distress_feed and warn_liquidation_map by focusing on asset mapping for receivership.

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 tells the user to pass a notice link from abc_distress_feed/abc_find_notices or an entity name, providing clear context for when to use this tool. It implies use for wind-down or buyer bidding, but lacks explicit when-not-to-use or alternative tools beyond the sibling list.

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 no annotations provided, the description carries full burden. It discloses the feed is free, covers specific states, and warns that wind-downs move fast. However, it does not detail error handling, rate limits, or pagination 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 informative with four sentences, each adding value. It is front-loaded with key details but could be slightly more concise without losing substance.

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 parameter and no output schema, the description fully covers the tool's functionality, coverage limitations, and data content. It provides sufficient context for an agent to understand and invoke 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?

Schema coverage is 100% for the single parameter 'limit', with a clear description in the schema. The description does not add extra meaning beyond the schema, so baseline score of 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?

The description clearly states the tool provides a live feed of ABC and receivership public legal notices, with specific details on notice types and coverage. It distinguishes itself from sibling tools like abc_asset_map and abc_find_notices by focusing on a broad, real-time feed.

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 usage for monitoring wind-down filings but does not explicitly state when to use this tool versus alternatives like abc_find_notices or warn_liquidation_map. It provides geographic context (WA as beachhead, dark states) but lacks when-not-to-use 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?

With no annotations, the description bears the burden of transparency. It discloses the return type ('matching notice headers + links') and hints at read-only operation (search). However, it does not address auth, rate limits, or side 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 two sentences with no fluff. It front-loads the core action and includes examples, then explicitly states the output and a downstream usage hint.

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 search tool with no output schema, the description covers purpose, input hints, and output type. It lacks details like pagination or error handling, but these are less critical for a straightforward keyword search.

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 baseline is 3. The description adds value by providing example keywords for the 'keyword' parameter, but does not elaborate on 'limit'. This modest addition keeps the score at 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?

The description uses a specific verb ('keyword-search') and resource ('wind-down legal-notice archive') with concrete examples, making the purpose very clear. It also distinguishes from siblings by implying a complementary role with abc_asset_map.

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 does not explicitly state when to use this tool vs alternatives, but the 'FREE' prefix and the mention of feeding results into abc_asset_map provide some context. No exclusions or alternative scenarios are given.

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 no annotations provided, the description carries the full burden. It discloses the data source limitation (CA WARN index joined to CO UCC only for multi-state operators), the hand-verifiable nature, and the payment requirement. It does not explicitly mention idempotency or whether it modifies state, but the 'map' context implies a read-only operation. The 'HONEST' clause shows good faith disclosure.

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 a single paragraph but front-loads the main purpose and key audience. It uses bold for emphasis and includes a separate payment note. While dense, every sentence adds value without redundancy. It could benefit from section breaks, but it remains appropriately sized for the tool's complexity.

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 no output schema, the description adequately describes the return value as 'encumbered-collateral inventory + liquidator/auctioneer/assignee actions' and the triage feed includes a 'CO-UCC collateral count'. It also covers the invocation conditions (entity vs none), data sources, and limitations. While a more detailed output structure would be helpful, the description is sufficient for an agent to understand the tool's output.

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%, establishing a baseline of 3. The description adds meaning beyond the schema by explaining the effect of passing an 'entity' (full map) vs omitting it (triage feed with CO-UCC collateral count) and mentioning the 'limit' parameter's role in the triage feed. This contextual guidance helps an agent choose 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 clearly states the tool builds a liquidator-facing asset/collateral map for a WARN-Act plant-death entity, specifying the verb 'build', the resource 'ASSET/COLLATERAL MAP', and the scope 'for a WARN-Act plant-death entity'. It distinguishes from siblings like abc_asset_map by highlighting the specific data joins (UCC, real property) and audience (liquidators, auctioneers, assignee).

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 explains the target users (distressed-asset liquidators, auctioneers, assignee) and their need for the map, and describes when to pass an entity (full map) vs omit it (triage feed). It also includes a caveat about the CA/CO limitation and a verification warning. However, it does not explicitly state when not to use the tool or name alternative tools from the sibling list.

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?

Despite no annotations, the description details output contents (failing employer, live Colorado UCC map indicator), data sources (CA EDD, CO UCC join), and data quality (honest null for uncovered states). It lacks rate limits or auth info but provides substantive behavioral 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 a dense, run-on paragraph with multiple clauses, metaphors ('lane', 'map', 'dying plant'), and jargon. It is not front-loaded nor easily scannable, sacrificing clarity for efficiency.

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 main use case, output fields, and sibling connection, but lacks practical details like recency window, pagination, or number of events returned. It is adequate but incomplete for operational use.

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 'limit' is fully documented in the input schema (max events, default 25). The description adds no additional meaning or constraints, so 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?

The description clearly states the tool lists recent WARN-Act plant-death events (mass layoffs/plant closures), distinguishing it as the second lane feeding a liquidation map. However, domain jargon (e.g., 'distress-event lane', 'collateral overlay') might obscure the core function for unfamiliar agents.

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 directs users to feed an employer into warn_liquidation_map for full collateral inventory, implying a sequential use case. But it does not specify when to avoid this tool, prerequisites, or alternative contexts for the other siblings listed.

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