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

With no annotations, the description carries full burden. It mentions 'latest export result' suggesting it retrieves data (read operation) and that uid 'may contain an escaped URL', adding some context. But it doesn't disclose behavioral traits like error handling, rate limits, authentication needs, or what 'result' entails (e.g., format, size).

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, efficient sentence with zero waste—front-loaded with the core action ('Get'), specifies the resource and constraint, and includes a helpful note about the uid. 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 1 parameter with full schema coverage and no output schema, the description is minimally adequate. It clarifies the tool's purpose and uid source, but as a read operation with no annotations, it should ideally explain more about the result (e.g., what data is returned) to compensate for the lack of output schema.

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%, so the schema already documents the uid parameter fully. The description adds marginal value by noting the uid 'may contain an escaped URL', but doesn't provide additional syntax or format details beyond the schema's description. Baseline 3 is appropriate as the schema does the heavy lifting.

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 'Get' and the resource 'latest export (convert) result', specifying it's for a parsed PDF uid. It distinguishes from siblings like doc2x_convert_export_submit (which submits) and doc2x_convert_export_wait (which waits), but doesn't explicitly contrast with status-checking tools like doc2x_parse_pdf_status.

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 after a parse task (uid from doc2x_parse_pdf_submit) and for getting results, not submitting or waiting. However, it lacks explicit when-not-to-use guidance or clear alternatives among siblings (e.g., vs. doc2x_parse_pdf_status for parse status).

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. It usefully discloses that this is an async job requiring polling and that parallel duplicate submissions for the same uid+format are forbidden, but says nothing about the immediate return value (task id?), whether resubmission after completion is allowed, or any cost or rate limit.

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 sentences totalling roughly 30 words. The action and the follow-up polling step come first, and the concurrency warning comes last. Nothing is padded, and the next-step information is 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 job-submission tool with 7 parameters, no annotations, and no output schema, the description adequately covers the workflow and the concurrency hazard. It is not complete enough to prevent wrong calls, because required-enum semantics and the return contract remain undocumented.

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 57%, and the gaps matter: required 'to' and 'formula_mode' (a required enum with values normal/dollar) and optional 'merge_cross_page_forms' have no descriptions anywhere. The description mentions only 'uid+format' and adds no meaning, such as how output formats differ or what formula_mode does.

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 names a specific verb ('Start') and resource ('an export (convert) job for a parsed PDF uid'), and it names the polling siblings, so the agent can tell it apart from doc2x_convert_export_wait and doc2x_convert_export_result. The async workflow is clear from the first sentence.

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?

It explicitly routes the agent to doc2x_convert_export_wait or doc2x_convert_export_result after submitting, and adds a concrete negative rule ('Do NOT call ... twice for the same uid+format in parallel'). The remaining gap is that it doesn't state the precondition that the parse must be finished, or how to retry after a failure.

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 at all, the description carries the full burden, and it does disclose a critical hidden side effect: this 'wait' tool can silently perform a write (submit an export job) when formula_mode is supplied and the job wasn't submitted in-process. That is genuinely valuable. However it says nothing about timeout semantics, whether max_wait_ms expiry raises or returns partial state, or whether waiting blocks/polls server-side.

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 short sentences, front-loaded with the primary action, followed by the preferred workflow, then the legacy exception. Nothing is padded, though the backward-compatibility sentence is dense enough that it could be parsed as covering the main path.

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 9-parameter polling/wait tool with no annotations and no output schema, the description explains the happy path and the legacy path but omits what a completed wait yields and what happens on timeout or failure. An agent can start the call but cannot fully predict its outcome or its error behavior.

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 only 44% across 9 parameters, so the description must compensate and only partially does: it names uid and to as the wait keys and ties formula_mode to the auto-submit trigger. The other six parameters (max_wait_ms, poll_interval_ms, filename, merge_cross_page_forms, filename_mode) get no treatment in the description, and formula_level is only inferable via the schema's own note that formula_mode must be provided.

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?

States a specific verb+resource: 'Wait for an export job to finish', and names the prerequisite sibling doc2x_convert_export_submit. It does not differentiate itself from doc2x_convert_export_result, which is the obvious other half of the flow, leaving some ambiguity about which call actually returns the artifact.

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?

'Prefer calling doc2x_convert_export_submit first, then wait with uid+to' gives an explicit ordering and the required arguments. The backward-compatibility path (formula_mode present + job not submitted in-process → auto-submit once) explains a second legitimate usage mode. No 'when not to use' guidance, e.g. that an already-finished job should go straight to the result tool.

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 of behavioral disclosure. It states the tool returns information for debugging, which implies it is a read-only, non-destructive operation. However, it lacks details on potential side effects, authentication needs, rate limits, or output format. The description adds basic context but does not fully compensate for the absence of annotations.

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, efficient sentence that front-loads key information ('Debug helper') and clearly states the action and purpose. There is no wasted language, and it effectively communicates the tool's role in minimal 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 complexity is low (0 parameters, no output schema), the description is somewhat complete for a debugging utility. However, without annotations or an output schema, it lacks details on what the returned config and API key source entail, such as format or structure. This leaves gaps in understanding the tool's full behavior and 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter-specific information, which is appropriate. A baseline of 4 is applied as per the rules for zero parameters, since the schema fully covers the lack of inputs.

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 as a 'Debug helper' that 'return[s] resolved config and API key source for troubleshooting.' It specifies the verb ('return'), resource ('resolved config and API key source'), and context ('for troubleshooting'), making the intent unambiguous. However, it does not explicitly differentiate from sibling tools, which are focused on conversion, download, and parsing operations, so it falls short of a perfect score.

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 context ('for troubleshooting'), suggesting this tool should be used when debugging issues, but it does not provide explicit guidance on when to use it versus alternatives or any exclusions. No sibling tools appear to serve a similar debugging purpose, so the implication is adequate but not comprehensive.

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 disclosure burden, yet it says nothing about side effects, that an existing file is overwritten, whether directories must exist, auth needs, or what is returned. The overwrite caveat exists only in the schema, not in the description.

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 front-loaded sentence with the action, source, and destination in that order, and no filler. Nothing could be removed without losing information.

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 two-parameter tool with fully documented parameters, the core is covered. But with no annotations and no output schema, the description should say what it returns (path? bytes? success flag) and confirm the overwrite behavior, which it leaves to the schema.

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% for both parameters, so the baseline is 3. The description adds one meaningful constraint beyond the schema: the URL is expected to be 'Doc2x-provided' (i.e., from doc2x_convert_export_result), narrowing acceptable inputs.

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?

States a specific verb (Download) and resource (a Doc2x-provided URL) with a defined destination (local file path), and ties the input to the sibling doc2x_convert_export_result. It does not, however, distinguish itself from the file-writing siblings like doc2x_materialize_convert_zip, which likely also produce local artifacts.

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 parenthetical '(e.g. from doc2x_convert_export_result)' implies the tool should be used after that call, giving implied sequencing. There is no explicit when/when-not guidance and no mention of when to prefer the materialize_* siblings instead.

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 of behavioral disclosure. It reveals the tool's 'best-effort' nature and two-step process (system unzip first, then write zip file), which adds useful context beyond the basic operation. However, it doesn't cover critical aspects like error handling, permissions needed for output_dir, or what 'materialize' entails in terms of file structure or overwrites.

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 appropriately sized with two concise sentences. The first sentence front-loads the core purpose, and the second adds behavioral context without redundancy. Every sentence earns its place by clarifying the operation and fallback mechanism, though it could be slightly more structured (e.g., bullet points for steps).

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 complexity of handling zip files and base64 encoding, with no annotations and no output schema, the description is incomplete. It misses key details: what 'materialize' means (extract? copy?), error responses, output format, or success indicators. For a tool with 2 parameters and significant behavioral nuance, this leaves the agent under-informed about execution and outcomes.

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%, so the description must compensate. It explains that convert_zip_base64 is a base64-encoded zip file to materialize and output_dir is the target directory, adding meaning beyond the schema's minimal type constraints. However, it doesn't detail format expectations (e.g., zip structure, encoding standards) or directory requirements (e.g., must exist), leaving gaps in parameter understanding.

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: materializing a base64-encoded zip file into an output directory. It specifies the verb 'materialize' and the resource 'convert_zip (base64)', which distinguishes it from sibling tools focused on conversion, parsing, or downloading. However, it doesn't explicitly differentiate from all siblings (e.g., doc2x_download_url_to_file might also handle files), so it's not a perfect 5.

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 no guidance on when to use this tool versus alternatives. It mentions a 'best-effort' approach with system unzip as a fallback, but doesn't specify prerequisites, error conditions, or comparisons to sibling tools like doc2x_convert_export_result. Without explicit when/when-not instructions, the agent lacks context for proper selection.

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 does disclose the key hidden behavior: it blocks/waits, it may submit a new parse task when only pdf_path is given, and it reuses a cached uid. It does not explain what happens on wait timeout (max_wait_ms), polling mechanics, or failure/partial-result behavior, which matter for a long-running blocking tool.

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 tight sentences with no filler; the core action and output destination lead, followed by parameter selection rules. Every sentence carries information the schema does not.

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?

Six parameters, no annotations, and no output schema, so the description carries the full burden. It covers the main execution path but omits timeout/polling semantics and what the written JSON contains beyond 'raw result with page layout', leaving the two undocumented integer parameters ambiguous.

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 67%; max_wait_ms and poll_interval_ms are completely undocumented in both schema and description. The description does add value the schema lacks — the uid-over-pdf_path preference and the cached-uid reuse rule — but leaves the timeout/polling knobs unexplained.

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?

Specific verb chain ('wait for a PDF parse task and write the raw Doc2x result JSON with page layout to output_path') plus a concrete resource and destination. The 'with page layout' and file-writing framing implicitly separate it from doc2x_parse_pdf_wait_text and doc2x_parse_pdf_status, but no sibling is named explicitly.

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?

'Prefer passing uid' and the pdf_path fallback rule give real guidance on how to call it, but nothing states when to choose this tool over doc2x_parse_pdf_wait_text, doc2x_parse_pdf_status, or doc2x_parse_image_layout_sync. Usage is implied by the layout-JSON output rather than contrasted with alternatives.

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 burden of behavioral disclosure. It mentions retrieving status/result for an async task, which implies a read-only operation, but does not detail potential behaviors like error handling, rate limits, authentication needs, or what the result format might be. For a tool with zero annotation coverage, this is insufficient transparency.

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, efficient sentence that front-loads the key information ('Get status/result') and includes essential context (e.g., 'async image-layout parse task by uid'). There is no wasted verbiage, making it highly concise and well-structured for quick understanding.

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 complexity of an async task status tool with no annotations and no output schema, the description is incomplete. It lacks details on what the status/result includes (e.g., progress indicators, error messages, or output data format), which is critical for an agent to use this tool effectively. The description does not compensate for these gaps.

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%, with the uid parameter fully documented in the schema as a string from doc2x_parse_image_layout_submit. The description adds minimal value by reinforcing the uid's purpose but does not provide additional semantics beyond what the schema already covers, aligning with the baseline score for high schema coverage.

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 specific action ('Get status/result') and resource ('existing async image-layout parse task by uid'), distinguishing it from siblings like doc2x_parse_image_layout_submit (which submits tasks) and doc2x_parse_image_layout_sync (which performs synchronous parsing). It precisely identifies the tool's function without being vague or tautological.

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 context by specifying 'existing async image-layout parse task by uid' and referencing doc2x_parse_image_layout_submit as the source of the uid, which guides when to use this tool. However, it does not explicitly state when not to use it or name alternatives like doc2x_parse_image_layout_wait_text, leaving some room for improvement in sibling differentiation.

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 of behavioral disclosure. It effectively describes the asynchronous nature of the operation, the return format, and the required follow-up workflow. However, it doesn't mention potential limitations like file size restrictions, supported image formats beyond png/jpg (implied by schema), or error conditions.

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 (two sentences) and front-loaded with the core purpose. Every sentence earns its place: the first explains what the tool does and returns, the second provides critical workflow guidance. 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 complexity (async workflow requiring follow-up calls), no annotations, and no output schema, the description does well by explaining the async nature and required subsequent steps. However, it doesn't describe what the parse task actually produces or potential error scenarios, leaving some gaps in completeness.

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%, so the schema already fully documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.

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 specific action ('Create an async image-layout parse task') and resource ('image-layout'), distinguishing it from siblings like doc2x_parse_image_layout_sync (synchronous version) and doc2x_parse_image_layout_status (status check). It explicitly mentions the return value format '{uid}' and subsequent required calls.

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 explicit guidance on when to use this tool versus alternatives: it specifies this is an async task that requires follow-up calls to doc2x_parse_image_layout_wait_text or doc2x_parse_image_layout_status with the returned uid. This clearly distinguishes it from the synchronous sibling tool.

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 synchronous behavior and return format (raw JSON with convert_zip), which is useful. However, it lacks details on error handling, performance expectations (e.g., timeouts for large images), or authentication needs, leaving gaps for a mutation-like tool.

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, efficient sentence that front-loads the core action and output. Every word earns its place, with no redundancy or unnecessary details, making it easy to parse quickly.

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 annotations, no output schema, and a single parameter with full schema coverage, the description is minimally adequate. It covers the purpose and output format but lacks context on errors, limitations (e.g., supported image types beyond png/jpg implied by schema), or integration with sibling tools, leaving room for improvement.

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%, with the schema fully documenting the 'image_path' parameter (type, constraints, path resolution). The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline but doesn't enhance understanding.

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 action ('parse an image layout synchronously') and the resource ('image'), specifying it returns raw Doc2x result JSON. It distinguishes from siblings like 'doc2x_parse_image_layout_submit' (async) and 'doc2x_parse_image_layout_wait_text' (text-focused), but could be more explicit about the distinction.

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 synchronous parsing of image layouts, but lacks explicit guidance on when to use this vs. alternatives like 'doc2x_parse_image_layout_submit' (async) or 'doc2x_parse_pdf_*' tools. It mentions 'convert_zip when present' as a feature, but no clear when-not scenarios or prerequisites are stated.

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 of behavioral disclosure. It effectively describes key behaviors: it's a blocking/waiting operation ('wait...until success'), it returns specific output ('first page markdown'), and it has caching logic ('reuse an in-process cached uid'). It doesn't mention error handling or rate limits, but covers the core operational flow well.

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 efficiently structured in two sentences. The first sentence states the core purpose and output. The second sentence provides crucial usage guidance for the two main parameters. Every word earns its place with no redundancy or fluff.

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 4 parameters, no annotations, and no output schema, the description does well by explaining the waiting behavior, output format, and parameter interplay. It could be more complete by mentioning what happens on failure or the format of the returned markdown, but it covers the essential context given the complexity.

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 50% (uid and image_path have descriptions, poll_interval_ms and max_wait_ms do not). The description adds significant value by explaining the semantic relationship between uid and image_path: uid is preferred to avoid resubmission, while image_path triggers either cache reuse or new submission. This clarifies parameter usage beyond the basic schema 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 specific action ('Wait for an image-layout parse task until success') and the resource involved ('first page markdown'). It distinguishes itself from siblings like doc2x_parse_image_layout_submit (which submits) and doc2x_parse_image_layout_status (which checks status) by emphasizing waiting for completion and returning output.

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 explicitly provides usage guidance: 'Prefer passing uid (no re-submit)' indicates when to use uid over image_path, and it explains the alternative flow when only image_path is provided (reuse cached uid or submit new task). This directly addresses when to use this tool versus its submit sibling.

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 of behavioral disclosure. It effectively describes the return structure ({status, progress, detail}), status values (processing/failed/success), progress range (0..100), and when detail is populated (only when status=failed). It also mentions the dependency on doc2x_parse_pdf_submit for obtaining the uid. However, it doesn't cover potential errors, rate limits, or authentication needs.

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 efficiently structured in two sentences: the first explains the tool's purpose and return values, the second provides critical usage guidance. Every sentence adds essential information without redundancy, making it easy for an agent to parse quickly.

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 moderate complexity (single parameter, no output schema, no annotations), the description is largely complete. It explains the return structure and tool relationships well. However, it could benefit from mentioning error handling or timeouts, which would make it fully comprehensive for a status-checking operation.

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%, so the schema already documents the uid parameter. The description adds meaningful context by explaining that the uid comes from doc2x_parse_pdf_submit, which helps the agent understand the parameter's origin and relationship to other tools. This goes beyond the schema's technical description.

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 specific action ('Query parse task status') and resource ('by uid'), distinguishing it from sibling tools like doc2x_parse_pdf_submit (which submits tasks) and doc2x_parse_pdf_wait_text (which waits for completion). It explicitly identifies the tool's role in checking status rather than initiating or retrieving content.

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 explicit guidance on when to use this tool: after submitting a parse task via doc2x_parse_pdf_submit (referenced in the parameter description) and before fetching content via doc2x_convert_export_* tools. It clearly differentiates this status-checking tool from content-retrieval alternatives.

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 behavioral disclosure burden. It usefully says this creates a task, returns a uid, and that progress should be monitored via status, but it does not mention permissions, upload side effects, failure behavior, or whether duplicate submissions are handled.

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 are front-loaded with the core action, return value, and sibling routing. There is no wasted text, and the usage caveat about doc2x_parse_pdf_wait_text is placed after the primary action.

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 two-parameter async submit tool with full schema coverage and no output schema, the description gives the essential action, return value, and next-step routing. It could be slightly more complete by explicitly tying the returned uid to doc2x_parse_pdf_status, but it is otherwise sufficient.

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%, so both pdf_path and model are already well documented in the schema. The description adds only that this is for a local file and that the result is a uid, without adding parameter-level meaning beyond 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 states a specific verb and resource: create a Doc2x PDF parse task for a local file. It also states the immediate return value ({uid}) and explicitly distinguishes this submit step from monitoring via doc2x_parse_pdf_status and doc2x_parse_pdf_wait_text.

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?

It explicitly routes monitoring to doc2x_parse_pdf_status and restricts doc2x_parse_pdf_wait_text to cases where the user explicitly asks to wait or return merged text. The intended use is clear: submit the local PDF first, then monitor through the named alternatives.

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 usefully discloses that it may submit a new task when only pdf_path is provided and that it may reuse an in-process cached uid. However, it omits important behavior around timeout/failure handling despite the max_wait_ms parameter, and does not describe polling or error 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?

The description is short, front-loaded, and every sentence contributes needed information. The uid preference and pdf_path fallback are expressed compactly without repetition.

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 an eight-parameter blocking/waiting tool with no annotations and no output schema, the description covers the core purpose and key uid/pdf_path behavior. It is still incomplete regarding timeout/failure behavior, polling, join semantics, and how the returned merged text is structured.

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 63%, and the description adds meaningful conditional semantics for uid versus pdf_path, including cache reuse and resubmission behavior. It still says nothing about join_with, max_wait_ms, or poll_interval_ms, so it does not fully compensate for the remaining schema coverage gaps.

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 states a specific action (wait for a PDF parse task), the condition (until success), and the result (merged text). It is clearly distinguishable from a submit or status tool, though it does not explicitly name sibling alternatives.

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?

It gives clear routing guidance: prefer passing uid to avoid resubmission, and if only pdf_path is given, it will reuse a cached uid or submit a new task before waiting. It does not explicitly compare this tool to doc2x_parse_pdf_status or doc2x_parse_pdf_submit, leaving some alternative-selection guidance implicit.

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