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

Annotations already disclose that the operation is destructive and non-idempotent. The description adds useful behavioral constraints beyond annotations: video inputs are reduced to audio, and the output extension must match the requested format. It does not explain overwrite semantics, keeping it short of a 5.

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 three short, front-loaded sentences with no filler. Each sentence adds operational detail about formats, video input handling, or output constraints.

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?

An output schema exists, so return values need not be described, and annotations cover the destructive safety profile. However, for a tool that can overwrite output files, the description omits overwrite behavior and does not fully compensate for the absent parameter descriptions.

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 does add meaningful semantics for input_path (may be video) and output_path (extension must match format), but it does not explain overwrite behavior, leaving one parameter's semantics to the schema and annotations.

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 ('Convert audio') and explicitly lists supported output formats. The note that video input keeps only its audio further sharpens the scope, making it clearly distinct from info-oriented siblings like audio_info or video_info.

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 the tool by describing conversion behavior, but it does not explicitly contrast it with audio_info, video_info, or explain when not to use it. Usage is inferable but not fully guided.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered structurally. The description adds only the list of metadata fields, which is already implied by the output schema; it does not mention failure behavior for unsupported/corrupt files or whether the file is read in full.

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 compact fragment, front-loaded with the resource and immediately followed by the most useful detail (the field list). No filler, though it is a noun phrase rather than a sentence, which slightly weakens the framing.

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?

Complexity is low, an output schema exists so return values need no prose, and annotations cover the safety profile. The remaining gaps — what input_path accepts and supported audio formats — are left entirely unaddressed, which is the minimum-viable rather than complete level.

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 carries full burden for input_path — yet it says nothing about whether the path is absolute or relative, local-only (openWorldHint=false suggests local), or which container formats are accepted. For a single required path parameter this is a meaningful 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 names the resource (audio metadata) and enumerates the concrete fields returned (duration, format, bitrate, sample rate, channels, codec), which makes the tool's job unambiguous and separates it from the mutating sibling audio_convert. It never states the verb explicitly ('retrieve/read'), but the intent is clear from the field list.

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 on when to use this versus audio_convert or video_info, and no mention of prerequisites such as the file needing to exist, be a supported format, or be locally reachable. The agent must infer all routing and preconditions.

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?

The annotations already establish that this is a safe, local read-only operation, and an output schema exists for return details. The description adds that it checks installed external components, which is useful behavioral context, but it does not disclose depth of checks, failure behavior, or performance traits.

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?

It is a single, front-loaded sentence with no wasted words. Every listed item contributes to understanding what the health check reports.

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 zero-parameter read-only health tool with annotations and an output schema, the description covers the essential scope. The phrase 'each external piece' is slightly vague, but nothing critical is missing for correct invocation.

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 takes zero parameters, so there is no parameter semantics burden and the baseline is 4. The description appropriately avoids discussing nonexistent 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 identifies a server health/status resource and enumerates what it reports: status, version, working directory, and installed external components. It is easy to distinguish from the media-specific *_info siblings, but it does not explicitly differentiate itself from lathe_modules or name 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?

The content implies a diagnostic/health-check use case, but there is no explicit guidance on when to call it versus other tools or when not to use it. The usage is inferable rather than 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?

Annotations already declare destructiveHint=true, idempotency=false and readOnlyHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral rule — that the output extension must correspond to the requested format, which is a validation failure mode. It says nothing about what overwrite destroys, however, which is the main destructive behavior.

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 short sentences, verb and resource front-loaded, no filler. Nothing in the text 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?

An output schema exists, so return values need not be described, and the destructive/overwrite risk is partly implied by annotations. Still, for a 4-parameter mutation tool with 0% schema coverage and a file-overwriting behavior, omitting any explanation of overwrite or path handling leaves a real 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 0%, so the description must carry the parameter burden and does not. It implies format values (png/jpeg/webp/avif/bmp) but never explains input_path, output_path, or the semantics of the overwrite flag, which is the most consequential parameter given destructiveHint=true.

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?

Names a specific verb (Convert) and resource (an image) and enumerates the five target formats, so an agent knows exactly what the tool does and can tell it apart from image_resize/image_optimize. It stops short of explicitly contrasting itself with those siblings, which keeps it at 4 rather than 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 only guidance is a constraint ("The output extension must match"), not a when-to-use rule. Nothing says when to pick image_convert over image_optimize or image_resize, nor when the optional overwrite should be enabled.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so mutation is disclosed structurally. The description adds the top-left origin rule, but says nothing about the overwrite parameter's effect, what happens when the output path already exists, or whether an out-of-bounds rectangle errors or clips — critical gaps for a destructive file-writing 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?

Two short sentences, no waste, and the coordinate convention — the most error-prone detail — is front-loaded. It is under-specified rather than bloated.

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?

An output schema exists, so return values need no explanation. For a destructive, 7-parameter file operation, however, the description omits overwrite semantics and bounds/error behavior, leaving meaningful 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 0%, so the description must compensate. It only clarifies x and y (pixels, top-left origin); width, height, overwrite, input_path and output_path are undocumented anywhere.

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 and resource ('Crop a rectangle from an image') and adds coordinate semantics. It does not distinguish itself from close siblings like image_resize or image_thumbnail, so the agent must infer which tool transforms geometry vs. scales.

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 on when to crop versus resize/thumbnail, and no mention of preconditions such as the crop rectangle having to stay within image bounds. The agent is left to discover failure modes on its own.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered, and the output schema carries the return shape. The one genuine addition is '(capped)' on EXIF tags, which signals truncated output — a real behavioral caveat. Beyond that it adds nothing about failure modes (non-image files, missing paths) or limits on the file size value.

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?

One short sentence that front-loads the resource and lists the returned fields compactly. Every token earns its place; no filler or restatement of the tool name. It reads as a fragment rather than a sentence, but that does not hurt clarity.

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?

Because an output schema exists, the description is not obligated to explain return values, and the safety profile is covered by annotations. What remains missing is any mention of path format expectations or error behavior for non-image input, which matters for an agent picking this tool blind.

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?

There is a single parameter, input_path, with 0% schema description coverage. The name is largely self-explanatory, but the description says nothing about whether it expects a local filesystem path, a relative path, or whether remote URLs are accepted. With only one obvious parameter this is a minor gap rather than a blocking one.

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 resource (image metadata) and enumerates exactly what is returned: width, height, format, mode, file size, and EXIF tags. This clearly separates it from the sibling tools, which are all mutations (resize, convert, crop, optimize, thumbnail) or operate on other media (pdf, audio, video). The only shortfall is that the verb is implicit rather than stated.

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?

There is no guidance on when to prefer this tool over alternatives or any preconditions for calling it. The read-only nature is implied by the field list but never framed as 'use this instead of X when you only need metadata'. An agent must infer usage entirely from the name.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact — metadata is stripped by default — but says nothing about what happens when the output file already exists or when overwrite=false, which matters for a destructive 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?

Two short sentences with zero filler; the core action is front-loaded and the surprising default (metadata stripping) follows immediately.

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?

An output schema exists, so return values needn't be explained, and annotations cover the safety profile. However, for a 5-parameter destructive mutation with 0% schema coverage, the description is too thin — most parameters and the overwrite/existing-file behavior are unaddressed.

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% across 5 parameters, so the description must carry the load. It explains only strip_metadata (including its default); quality, overwrite, input_path, and output_path are left entirely undocumented, and overwrite's interaction with destructiveHint is unmentioned.

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 ('Shrink') and resource ('an image') with a clear end goal ('for web delivery'), which distinguishes it from siblings like image_resize or image_convert. It doesn't explicitly name those siblings, so it stops short of a 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 phrase 'for web delivery' implies the use case, but there is no explicit when-to-use versus image_resize/image_convert/image_thumbnail guidance and no prerequisites. Usage must be inferred from the sibling list.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the bar is lower. The description adds useful behavior (aspect-ratio preservation, output format inferred from the extension), but says nothing about what happens when the output file already exists or how the 'overwrite' flag changes that, which is exactly the risk the destructive hint flags.

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 operation and its main modes, then the two behavioral rules. Nothing redundant.

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 an output schema present, return values needn't be described, and the destructive annotation covers the risk profile. Still missing for a destructive 6-parameter mutation: overwrite semantics, mutual exclusivity of sizing parameters, and any error/validation guidance.

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 carry parameter meaning; it partially does, explaining the roles of width, height, and percentage and the aspect-ratio rule. It leaves 'overwrite' undefined and never states precedence when width, height, and percentage are supplied together — a meaningful ambiguity for a 6-parameter tool.

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 and resource ('Resize an image') plus the three supported sizing modes, so the agent immediately knows the operation. It doesn't distinguish itself from near-siblings like image_thumbnail or image_convert, which is the only gap.

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 by the behavioral rules ('keeps the aspect ratio when only one dimension is given', format from output extension), but there is no explicit when-to-use/when-not guidance and no mention of when image_thumbnail or image_convert would be preferred.

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?

The annotations declare destructiveHint=true and readOnlyHint=false, so the safety profile is already known, but the description adds nothing about the important behavior of whether an existing output_path is overwritten, what happens when it already exists, or which formats are supported. It only restates the scaling rule, which is more purpose than behavior.

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?

It is a single front-loaded sentence with no filler and the key geometric constraint stated immediately. It is efficient, but it omits essential detail rather than being over-specified.

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?

An output schema exists, so return values needn't be described, but for a destructive write tool with four undocumented parameters, the description is not complete enough for confident invocation. Nothing covers overwrite semantics or failure modes.

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 explain the four parameters, but it only hints at 'size' via 'square of the given size'. input_path, output_path, and especially overwrite, whose default is false, are undocumented anywhere, so this real gap cannot be compensated.

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 result: it makes a thumbnail bounded by a square of the given size while preserving aspect ratio. That semantics distinguish it from the image_resize sibling, even though the sibling is not 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?

The description offers no guidance about when to use this tool versus image_resize or image_crop, nor any prerequisites or exclusions. The usage context is only inferable from the word 'thumbnail'.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing what the response contains: availability state, missing pieces together with their install commands, and tool descriptions. It stops short of noting anything about cost or freshness of the module list, but for a read-only introspection call this is solid.

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, no filler, and the primary output (which modules are on) is front-loaded ahead of the optional-parameter note. The parenthetical about install commands earns its place by telling the agent the response is actionable.

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?

An output schema exists, so return values need not be spelled out here, and annotations cover the safety profile. The description still conveys the two invocation modes and the nature of the payload, which is everything an agent needs to call a one-optional-parameter introspection tool correctly.

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% and the single `module` parameter has no description, so the description must carry the burden. It partially does, explaining that passing a module name returns that module's settings, which establishes the overview-vs-detail semantics. It does not say what form the name takes (must it match a name from the overview list? case sensitivity?), leaving a real 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 names a concrete resource (modules) and three specific outputs: enabled modules, missing pieces with install commands, and per-tool descriptions. That is enough to separate it from every sibling, which are all media conversion utilities. The phrasing is conversational rather than verb-first, but the scope is 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?

Usage is only implied: the second sentence tells the agent to pass a module name to get settings, which implicitly contrasts the no-arg overview mode with the single-module mode. There is no guidance on when to reach for this tool (e.g., before calling other tools, or when a tool fails due to a missing dependency), and no exclusions.

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?

Annotations already declare readOnly/openWorld=false, and the description adds real value beyond them: output is paginated in parts and 'next_offset' is the cursor to feed back, plus 'lang' overrides the LATHE_OCR_LANG environment variable. It doesn't say what happens on unsupported formats or empty text, and the pagination pointer depends on an output field the agent must infer.

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 short sentences, core purpose first, then the pagination mechanic and the language override. Nothing is wasted.

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?

An output schema exists, so return values needn't be explained, and the description covers the trickiest behavior (pagination). The only real gap is max_chars, whose truncation semantics are left silent.

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 carry the load. It explains offset (as the continuation cursor) and lang (as an env-var override), but leaves max_chars and input_path entirely 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?

States a specific verb and resource: 'Extract the text from an image with OCR'. That uniquely separates it from pdf_extract_text and the info/resize/convert siblings, though it never names an alternative 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?

The continuation rule ('pass next_offset as offset to continue') is a concrete usage instruction, but there is no guidance on when to pick this over pdf_extract_text or when OCR is inappropriate.

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?

Goes well beyond the annotations by disclosing the lossless method (recompress streams, remove duplicate objects), that images are not re-encoded, that exactly one new file is written, and the overwrite condition. This meaningfully reassures against the destructiveHint=true annotation. It does not mention failure modes or permissions, keeping it just below top marks.

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 tightly packed sentences, front-loaded with the core action and followed by the behavioral qualifiers. No filler or 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 a 3-param mutation tool with an output schema and rich annotations, the description covers the essential behavior (lossless, single output, overwrite gating). Minor gaps remain around path semantics and error/permission behavior, but nothing critical is missing for correct invocation.

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 carries the burden. It adds real meaning for 'overwrite' ('never overwrites unless overwrite=true') but says nothing about input_path/output_path beyond what their names convey, leaving the path parameters undocumented.

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 and resource ('Write a smaller copy of a PDF') and immediately qualifies how ('lossless... images are not re-encoded'), which cleanly separates it from sibling tools like pdf_merge or pdf_split that also produce PDFs.

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 compression intent is implied by the lossless-recompression explanation, but there is no explicit when-to-use guidance or named alternative (e.g., vs image_optimize or other PDF tools). An agent can infer purpose but gets no routing rules.

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?

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavior — conditional OCR depending on installation and output truncation/parting semantics. It does not state what happens when OCR is not installed (silent empty text vs error).

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 compact sentences, front-loaded with purpose, with the inline "2-5" example earning its place. No filler, though each sentence is dense rather than fully self-explanatory.

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 an output schema present, return values need not be explained, and the key behavioral caveats (OCR, pagination) are covered. A 5-param tool could still use a note on max_chars truncation thresholds, but the essentials are present.

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 carry parameter meaning and only partially does: pages syntax and offset continuation are explained, but max_chars (the truncation control driving the "parts" behavior) and ocr_fallback toggle are never mentioned. Partial compensation 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?

States a specific verb (extract) and resource (text from a PDF), with page-range scoping. It does not name the sibling alternatives (pdf_info, ocr_image, pdf_to_images) that an agent might confuse it with, but the core purpose is 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?

Gives concrete operational guidance: page ranges in "2-5" form, automatic OCR fallback when installed, and continuation via next_offset→offset for long output. It stops short of naming when to prefer ocr_image or pdf_info instead, so there are no explicit exclusions.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds essentially only a list of returned fields, which duplicates the output schema and does not disclose behavior on corrupt, password-protected, or missing files.

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 line with no filler; every item listed is a real output field. It is efficient, though efficiency here partly reflects under-specification rather than disciplined editing.

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 one-parameter read-only tool with an output schema that already documents return values, the description is close to sufficient. The remaining gap is the undocumented input_path parameter and the absence of any note on failure modes for invalid or encrypted PDFs.

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?

There is one parameter (input_path) with 0% schema description coverage, so the description carries the full burden of explaining it — and it never mentions the parameter at all. It does not say whether the path is absolute or relative, or what filesystem scope is expected.

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 the resource (PDF metadata) and enumerates the concrete fields returned (page count, file size, encryption, title, author, creator), which is enough to distinguish it from pdf_extract_text, pdf_merge and the image/audio/video_info siblings. However, it is a noun-phrase fragment with no verb ("get"/"read"), so the action must be inferred.

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?

There is no guidance on when to call this versus pdf_extract_text or the other *_info tools, and no mention of preconditions such as the path needing to exist. The agent must infer everything about selection from the sibling names alone.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds the useful ordering constraint but omits that a write occurs to output_path and that overwrite defaults to false, which matters for a destructive operation.

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 no filler. Every clause earns its place by conveying ordering and output creation.

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?

An output schema exists, so return values need no explanation, but for a destructive mutation with zero schema coverage the description should disclose the overwrite behavior and output-writing side effect. It is adequate but leaves a meaningful 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 0%, so the description must carry the burden, but it only clarifies the ordering semantics of input_paths. It says nothing about the overwrite flag's effect or about what output_path expects.

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 (merge), a specific resource (PDFs), the ordering semantics ('in the order given'), and the outcome ('into one new PDF'). This is clearly distinguishable from siblings like pdf_info, pdf_extract_text, and pdf_to_images.

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 by the operation itself, but the description gives no explicit when-to-use/when-not guidance, no mention of alternatives, and no note on prerequisites such as whether inputs must exist or be unencrypted.

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?

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds genuinely useful context: new files are written into a folder and existing files are never overwritten unless overwrite=true. That directly tempers the destructive hint and is the key safety detail an agent needs. It still omits output file naming and what happens when page count isn't a multiple of N.

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 short sentences with zero filler; the core action is front-loaded and the overwrite safety constraint follows immediately. 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?

An output schema exists, so return values need not be explained. However, for a destructive file-writing tool with 0% schema coverage, the description should say more about output file naming, behavior with an existing output directory, and what happens to the source PDF.

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 carries the burden. It explains the overwrite parameter semantics and implies pages_per_file ('N pages each'), but input_path and output_dir get no added meaning beyond their names, and defaults/constraints (pages_per_file min 1, max 10000, default 1) are left to 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?

States a specific verb and resource ('Split a PDF into parts of N pages each') and the side effect (writes new PDFs into a folder). It is unambiguous against siblings like pdf_merge or pdf_compress, though it does not explicitly name or route away from any sibling.

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 by the operation itself (splitting a PDF), but there is no explicit 'use this when...' guidance, no note on when to prefer pdf_extract_text or pdf_merge, and no stated prerequisites such as the PDF existing or the output folder being creatable.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotence, so the safety profile is covered. The description adds real value with the external ghostscript dependency, but it never explains what overwriting means, whether existing files in output_dir are clobbered, or failure behavior for a destructive write 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?

Two short sentences, transformation stated first, constraint appended. No filler, no restating of the tool name.

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 six parameters at 0% schema coverage and a destructive write profile, the description leaves page-range syntax, overwrite semantics, and output naming conventions undefined. The output schema does relieve it of explaining return values, but the input-side gaps remain substantial.

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 carry parameter meaning, but it only glosses format (PNG/JPEG), DPI, input PDF, and output folder. It says nothing about the "pages" parameter's syntax for selecting page ranges or what "overwrite" actually governs.

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 and transformation ("Render PDF pages to PNG or JPEG files") plus the output medium (a folder) and quality control (chosen DPI), which cleanly separates it from siblings like pdf_info, pdf_extract_text, and image_convert. It does not explicitly name the alternative tools an agent might confuse it with.

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?

There is a dependency note ("Needs ghostscript") but no statement of when to pick this over pdf_extract_text, ocr_image, or image_convert, and no exclusions. An agent must infer usage entirely from the one-line purpose.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile and locality are covered. The description adds nothing beyond that: it doesn't say whether it fails on missing/unsupported files or that the fields it lists are also in the output schema (it largely restates them).

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?

One short sentence with zero padding, which is good, but it is front-loaded with return fields that the output schema already enumerates rather than with the action being performed.

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 an output schema present, the return values needn't be explained, and annotations cover the read-only nature, so the remaining burden is small. Still missing: what form input_path takes and what happens on invalid input, for a tool whose only failure surface is the path.

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% and the sole parameter input_path is undocumented in both places. The description never mentions the parameter, so it does not compensate — it's unclear whether input_path is a local filesystem path or a URL.

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 the resource (video) and enumerates the metadata it surfaces, which lets an agent distinguish it from image_info/pdf_info/audio_info siblings. But it is a noun fragment with no verb, so it never states that the tool reads/inspects a video file rather than, say, writing metadata.

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 when-to-use guidance, no prerequisites, and no mention of the audio_info sibling that arguably overlaps on the audio-tracks field. The agent must infer from the name alone that this is the inspection step before video_thumbnail.

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?

Annotations already declare write and destructive behavior. The description adds useful context that the operation saves a frame at a timestamp and supports PNG/JPEG, but it does not explain overwrite behavior or what happens to an existing output file.

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 with no wasted words. It conveys the core action and the key timestamp unit efficiently.

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 output schema covers return values, and annotations cover the destructive write profile. Still, for a file-writing tool with undocumented parameters, the description should explain overwrite semantics and how the output format is selected.

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?

With 0% schema description coverage, the description partially compensates by clarifying that timestamp is in seconds and that output can be PNG or JPEG. However, it does not explain the overwrite parameter or output format determination, leaving meaningful 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 verb and resource: saving one video frame as a PNG or JPEG. It clearly distinguishes video frame extraction from image-oriented siblings, though it does not explicitly contrast with video_info.

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?

There is no guidance on when to use this tool versus alternatives such as video_info or image_thumbnail. The description implies extraction use but gives no conditions, prerequisites, or exclusions.

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?

Annotations already mark it destructive and non-idempotent, and the description adds useful safety context: it writes one new file and does not overwrite unless overwrite=true. It does not cover failure modes or whether the input file is ever modified.

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 constraints. Every clause adds meaningful information with no repetition 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?

An output schema exists and annotations cover the safety profile, so return values and risk are partly handled elsewhere. Still, for a seven-parameter mutation tool, the definition leaves most parameter meanings and path/format expectations 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 description coverage is 0%, so the description must compensate. It only clarifies overwrite behavior and the 30-second duration limit, leaving fps, start, width, input_path, and output_path without semantic explanation beyond their names.

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 and resource: make an animated GIF from part of a video, with constraints. The output type clearly separates it from siblings like video_trim and video_thumbnail, though it does not explicitly name 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?

The description implies usage for extracting a video segment as a GIF and gives a 30-second cap. However, it does not state when to choose this over video_trim, video_thumbnail, or other conversion tools.

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?

Beyond the annotations (destructiveHint=true, non-idempotent), the description discloses that stream copy is fast and lossless, that cuts snap to keyframes, and that an existing output is never overwritten unless overwrite=true. The keyframe caveat is exactly the kind of behavioral trait an agent could not infer from structured data.

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 tightly packed sentences, front-loaded with the operation and immediately followed by the two facts that affect correctness (losslessness/keyframes, overwrite safety). No sentence is 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?

An output schema exists, so return values need not be described, and the safety profile is covered. The remaining gap is the meaning of start/end (units, null end, inclusivity) for a destructive tool with zero schema documentation, which the description leaves unresolved.

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% across 5 parameters, so the description must compensate and only partly does: it explains overwrite semantics but never gives units or meaning for start/end, nor what a null end implies (presumably trim to end of file). input_path/output_path are self-evident but undocumented.

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 ("Cut a section out of a video into a new file") and names the mechanism (stream copy). An agent can distinguish this from siblings like video_info, video_thumbnail, or video_to_gif without opening any schema.

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 use case is implied clearly (extracting a segment to a new file), but no alternative is named and no when-not condition is stated. The keyframe caveat functions as a soft usage boundary, yet the description never says what to do when frame-accurate cuts are required.

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