compliance-evidence

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

No annotations provided, so description carries full burden. It discloses that the tool does not make compliance claims, uses trap-fact refusals, and outputs a hash-chain receipt. Transparent about limitations and methodology.

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 dense paragraph; it is informative but could be better structured with bullet points for clarity. No wasted sentences.

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

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

Given three parameters and no output schema, the description sufficiently explains what the tool produces (EVIDENCE ARTIFACT with hash-chain receipt) and how parameters relate. Minor gap: no details on ticket processing other than grounding.

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

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

Schema coverage is 100% with descriptions. Description adds value beyond schema by explaining trap-fact battery default, max limits on tickers and entities, and entity format expectations.

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?

Description clearly states the tool builds a compliance-evidence pack for a regulated-AI deployer, specifying it is dated, source-linked, and signed. It distinguishes from siblings by detailing unique features like contradiction engine and exclusion screening.

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 in regulatory compliance contexts but does not explicitly compare to siblings like ground_claim or screen_entity. No when-not-to-use guidance is provided.

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?

No annotations are provided, so the description carries full burden. It clearly states the tool returns a dual-cited record if a contradiction exists, otherwise an explicit null message describing the check result. It also mentions 'live contradiction-engine' and 'audit evidence', providing strong 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 single sentence but packed with relevant details. It is not overly verbose, though splitting into multiple sentences could improve 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?

Given the lack of annotations and output schema, the description explains the core behavior and return values. However, it omits details about what constitutes a 'claim', error scenarios, and how the ticker parameter is used. The tool is simple, so the gaps are noticeable.

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 has 0% description coverage for the single required parameter 'ticker'. The description mentions 'one public-company claim' but does not define how the claim is identified or that 'ticker' is the stock symbol. This leaves ambiguity about the parameter's role.

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 specifies the action 'Ground' a public-company claim against government facts using a contradiction engine, and clearly states the output conditions. However, the verb 'Ground' is jargon and not immediately clear, and the description does not explicitly distinguish from sibling 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 implies the tool is used when you have a public-company claim to verify, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.

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?

No annotations provided, so description carries full burden. It discloses checking specific lists (OFAC SDN, OFAC Consolidated, OIG LEIE; SAM where enabled), being live via exclude-feed, and being FCRA-safe. This adds useful behavioral context beyond just 'screen entity'.

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 core action and specific lists, followed by legal context. Every sentence adds value 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?

The description explains purpose and usage well but omits parameter semantics and output behavior. With 4 parameters and no output schema, the description could do more to guide the agent on how to use optional fields (npi, uei, state) and what the result looks like.

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 0% (no parameter descriptions in schema). Description does not explain any of the four parameters (npi, uei, name, state) beyond implying 'name' is the entity to screen. It fails to add meaning to the parameters, which is a significant gap given the schema has no descriptions itself.

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?

Description clearly states it screens a named entity across federal exclusion/sanctions lists, specifying exact lists (OFAC SDN, etc.). It distinguishes from sibling tools (build_evidence_pack, ground_claim, verify_pack) which are not about screening.

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?

Description gives clear usage context: FCRA-safe KYB/sanctions screening, explicitly stating it is not a consumer report. While it doesn't give explicit when-not-to-use or alternatives, the context is sufficient for an agent to understand when to invoke.

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?

No annotations are provided, so the description carries the burden. It mentions 'hash-chain receipt' and 'unaltered' but does not disclose behavioral traits like error handling, side effects, or whether it is a read-only operation. Adequate but could be more explicit.

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 wasted words. The description is front-loaded with the core action and purpose. 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?

Given no output schema and no annotations, the description lacks details about return values, verification failure indicators, or what a 'hash-chain receipt' entails. It is incomplete for a verification tool.

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

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

Schema description coverage is 0%, yet the description only says 'Pass the pack id.' This adds minimal value beyond the schema, which already indicates 'id' is a required string. It does not explain format or constraints.

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 verb 'Verify' and specifies the resource ('pack's hash-chain receipt'). It explains the purpose ('proves the artifact is unaltered since generatedAt') and distinguishes from sibling tools like 'build_evidence_pack' and 'ground_claim'.

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 instructs to 'pass the pack id', providing clear usage context. However, it lacks explicit guidance on when not to use the tool or mention of alternatives, though the context is unambiguous.

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