lc-checker

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

No annotations are provided. The description uses 'poll' but does not clarify if the call blocks, returns a status for incomplete jobs, or has timeout/retry behavior. Important behavioral traits are missing.

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 that conveys core information efficiently. It could be slightly more concise by removing redundant phrasing, but overall it is well-structured and front-loaded.

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 poll tool with one parameter and no output schema, the description covers what is returned. However, it lacks critical polling semantics (e.g., when to call, error handling), leaving gaps for the agent.

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

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

Schema description coverage is 0%. The description does not explain the job_id parameter beyond being an identifier; no format, expected type (integer or string), or how to obtain it is mentioned.

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 specifically states it polls an audit job and fetches verdict, per-rule findings with citations, and report paths. It clearly distinguishes from the sibling start_lc_audit by describing a retrieval operation vs. a creation operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (after starting an audit), but no explicit guidance on when to poll, whether the job must be complete, or when alternatives (such as waiting for a callback) might be appropriate.

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 must disclose all behavioral traits. It mentions async nature, polling requirement, and non-guarantee caveat. However, it does not cover potential errors, rate limits, or authentication needs. Adequate but not thorough.

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 efficient sentences: first defines action and domain, second explains return value and next step, third sets expectations. No wasted words.

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 tool's low complexity (start async audit, return job_id) and no output schema, the description fully covers what an agent needs: purpose, async nature, parameter context, and polling instruction. Complete for 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?

Schema description coverage is 100%. The description adds context for the 'ruleset' parameter (omit for default, 'lc-presentation' for specific) and for documents (1-12, auto-detected doctype). This goes beyond the schema's descriptions.

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 starts a UCP600/ISBP letter-of-credit audit over documents, returns a job_id, and instructs to poll with get_lc_audit_result. This distinguishes it from its 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 explains when to use (to start an audit) and that it is async (poll with get_lc_audit_result). It also sets expectations (decision support, not guarantee). However, it does not explicitly state when not to use or provide alternatives beyond the sibling.

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