check_lookup

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

With no annotations provided, the description carries the full burden of disclosure. It conveys a read-only polling action but does not describe expected behavior such as whether it returns the final result or a job status, how it handles in-progress or failed jobs, or any rate limits. This lack of detail is a notable gap for a tool that will be invoked iteratively.

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, front-loaded sentence that efficiently conveys the tool's purpose. Every word earns its place, with no redundant or extraneous 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is too sparse. It fails to explain what the response will contain (e.g., whether it returns the actual enrichment result or just a status), or how to interpret the poll outcome. This missing information is critical for an agent to know how to handle the result and decide next steps.

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 provides complete coverage of the single parameter 'jobId' with a clear description referencing submit_lookup. The tool description adds minimal extra meaning beyond what the schema already states, merely echoing that the job is created with submit_lookup. Therefore, it meets the baseline for high schema coverage without adding significant new information.

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's action ('Poll') and resource ('the result of an enrichment job'), and it explicitly references the sibling tool 'submit_lookup' for job creation. This distinguishes it from the sibling tools and leaves no ambiguity about its 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 implies the proper usage: after creating a job with submit_lookup, use check_lookup to poll its result. It provides clear context for when to use this tool, though it does not explicitly state when not to use it or mention any alternatives beyond the implied sequence.

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