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

With no annotations, the description carries the full burden. It discloses that the operation is irreversible and that it also removes the uploaded file and preview image, which is beyond the obvious 'delete job' action. It does not mention error behavior or idempotency, but the destructive scope is clear.

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 concise sentence that front-loads the primary action and immediately states consequences. Every word adds value, with no waste.

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 delete tool with one parameter, the description covers key behavioral aspects like irreversibility and associated file deletion. However, it lacks usage context, parameter semantics, and any mention of return behavior or error conditions, leaving gaps given absent annotations.

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 contains only job_id with no parameter description, and schema coverage is 0%. The tool description does not mention job_id or explain its meaning, format, or how to obtain it, failing to compensate for the schema gap.

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 deletes a job and its associated files/preview image, with a specific verb and resource. It distinguishes itself from sibling tools like get_job and parse_file by indicating a destructive removal action.

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?

No guidance is provided on when to use this tool versus alternatives, such as whether deletion should occur after job completion or if there are prerequisites. The description offers no exclusions or cautions beyond irreversibility.

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 carries the full burden and does disclose the return values (PENDING, PROCESSING, COMPLETED, FAILED). The read-only nature is clear from 'Check', and the tool's behavior is predictable. It lacks explicit mention of error handling or polling implications, but this is minor for such a simple status endpoint.

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, directly states the action and the possible return values, with no wasted words. 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 tool with one well-documented parameter and no output schema, the description is complete. It explains what statuses can be returned, which is sufficient for an agent to understand the tool's role in the parse workflow.

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 for job_id, including its source ('returned by parse_file/parse_url'), so the description adds no additional parameter semantics. The baseline of 3 applies since the schema already documents the parameter fully.

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 tool's purpose with a specific verb ('Check') and resource ('status of a CAD parse job'), and it distinguishes from siblings by listing the exact status values returned. It is immediately obvious this tool is for status polling, not for results or management.

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 usage context by referencing job_id from parse_file/parse_url, reinforcing the expected flow. However, it does not explicitly name alternatives like list_jobs or get_result, so the agent must infer when to choose this tool over 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 are provided, so the description carries the full behavioral burden. It discloses that the 'full' mode can be very large, which is useful. However, it doesn't mention failure modes (e.g., job not found, still running) or explicitly state read-only behavior beyond the verb 'Fetch'. The prerequisite 'completed' is mentioned but not elaborated.

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 purpose, followed by concise mode usage. Every phrase earns its place with no filler or 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 result-retrieval tool with 4 params and no output schema, the description covers the essential modes, the size warning, and the completion prerequisite. It could be slightly more explicit about the nature of the 'summary' output, but the sibling tools provide enough context for an agent to select and invoke this tool successfully.

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 50%, with descriptions only for layer_name and entity_type. The description adds value by explaining the meaning of each mode and clarifying that 'full' returns large JSON. It doesn't describe job_id, but that's self-explanatory. The conditional requirements are already in the schema, so the description adequately compensates for the coverage gap.

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 starts with 'Fetch the parsed result of a completed CAD job', using a specific verb and resource. It clearly differentiates from sibling tools like cadlens_get_job (status) and cadlens_parse_file (creation) by focusing on parsed results of completed jobs.

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 on when to use this tool (after completion) and provides mode-specific guidance (summary, entities_by_type, entities_on_layer, full). It doesn't explicitly mention alternatives or exclusions, but the sibling context and 'completed' prerequisite make the usage 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?

Discloses the 100-job limit, newness ordering, and API key scoping, which is useful behavioral context. However, with no annotations provided, it does not explicitly state read-only nature or what each job entry includes, leaving some transparency gaps.

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?

A single, well-structured sentence that front-loads the action ('List') and packs all key details (scope, order) without any filler. Excellent conciseness.

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 list tool with no parameters and no output schema, the description covers the essential scope and ordering constraints. It could mention the structure of returned job items, but given sibling tools and simplicity, it is sufficiently complete.

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 an empty schema, so there is nothing to document. The baseline for 0-param tools is 4, and the description appropriately adds no unnecessary param details.

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 ('List') and clearly identifies the resource ('CAD parse jobs') with precise scoping ('100 most recent', 'newest first'). It distinguishes from sibling tools like get_job (single job) and delete_job (deletion).

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 retrieving recent jobs but does not explicitly state when to use this over alternatives like get_job or how it differs from listing via other means. Sibling names make the distinction inferable, but the description lacks direct 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?

No annotations are provided, so the description carries the behavioral burden. It discloses that the tool polls until completion or 5 minutes elapse, and that it returns a summary including a preview image URL. This gives a clear operational model, though it doesn't detail failure modes or timeout behavior outcomes.

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 straightforward sentences cover formats, size limit, execution behavior, return value, and next-step tool. Every sentence earns its place with no redundancy or 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?

With no output schema, the description explains the return summary and preview URL, and points to cadlens_get_result for detailed data. The overall workflow is sufficiently sketched, though it omits explicit mention of job status fields or error handling.

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 covers all three parameters at 100% coverage, so the description adds no new parameter syntax or format details. It does contextualize the returned job_id as the input for cadlens_get_result, but that is not parameter-specific.

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 parses local CAD files, lists supported formats (DWG/DXF/DWF/DWFx/DGN-V7/PDF), and specifies a 100 MB limit. The word 'local' distinguishes it from the sibling cadlens_parse_url, making the resource and scope unambiguous.

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 for local files vs. URLs (via 'local') and explicitly directs users to call cadlens_get_result with the returned job_id for detailed entity data. It provides a clear next step but does not explicitly contrast with cadlens_parse_url or list disallowed scenarios.

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 carries the full burden of disclosing behavior, but it only mentions a size limit (max 100 MB) and the action of parsing. It fails to disclose whether parsing is asynchronous (despite webhook_url and notify_email parameters suggesting a job-based flow), what the response format is, what happens after parsing, or any side effects. The reference to 'Same output as cadlens_parse_file' is vague without sibling details.

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 extremely concise, containing two short sentences that front-load the key action and size limit. No unnecessary words or repetition—every word 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 the lack of output schema and annotations, and the presence of webhook/notify parameters that hint at job-based asynchronous behavior, the description is incomplete. It does not explain the return structure or job mechanics, and the webhook_url parameter is left undocumented. The brief reference to a sibling tool does not fill this 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 description coverage is 67% (url and notify_email have descriptions, webhook_url does not). The description adds the 100 MB size constraint for the url parameter, which is not in the schema. However, it does not clarify webhook_url, leaving a parameter unaddressed. Overall, the description adds marginal value but relies mostly on the schema.

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 function: 'Download a CAD file from a URL (max 100 MB) and parse it.' It uses specific verbs (download, parse) and a resource (CAD file from URL), and distinguishes itself from the sibling tool cadlens_parse_file by explicitly noting 'Same output as cadlens_parse_file' while differing in input source.

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 this tool (when you have a URL to a CAD file) and explicitly references an alternative (cadlens_parse_file) by stating the output is the same. However, it does not explicitly state when not to use it or provide a direct comparison beyond the sibling mention.

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 burden of disclosing behavior. It discloses that the URL is valid for 3600 seconds (expiration) and that it is cheaper than re-fetching the full result, which are meaningful behavioral traits. It does not mention potential errors or prerequisites beyond 'completed job', but the key behaviors are covered.

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, front-loaded with the primary action, and directly followed by a cost-saving note and validity duration. Every word contributes to understanding the tool, with no redundancy or 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, single-parameter tool with no output schema, the description covers the essential context: what it does, when to use it, cost implications, and URL expiration. It does not explicitly state the return value (the URL), but this is strongly implied. Minor gaps remain regarding error behavior for non-completed jobs, but overall it is sufficiently complete.

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%, so the description must compensate. It does not explicitly explain the job_id parameter, but the name and context ('for a completed job') imply its role. Given the single, self-explanatory parameter, the description adds minimal semantic value beyond what is already evident from the schema.

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 purpose: 'Re-fetch the presigned preview-image URL for a completed job.' This specific verb+resource distinguishes it from sibling tools like cadlens_get_result, and the cost comparison 'Cheaper than re-fetching the full result' further differentiates its use case.

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 provides clear context for when to use this tool: when you need the preview image URL for a completed job and want to avoid the cost of fetching the full result. It implies a usage scenario but does not explicitly state alternatives or exclusions, though the comparison to 'full result' serves as guidance.

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