tool_extract_imagesExtract embedded images from PDFs as PNG files. Use list_only to preview image details without saving, or set overwrite to replace existing files.
抽取 PDF 内嵌图片为 PNG；list_only=true 只返回图片清单不落盘。
overwrite=true 才允许覆盖同名图片。
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| pages | No | ||
| out_dir | No | ||
| list_only | No | ||
| overwrite | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.6Input schema / properties / overwriteAdded value: +{
+ "default": false,
+ "type": "boolean"
+}v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It usefully discloses that list_only=true avoids writing files and that overwrite=true is required to replace same-named images, implying default write behavior and overwrite protection. However, it does not mention default output directory behavior, page handling, or error cases, leaving meaningful gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and uses a clear newline to separate high-level behavior from parameter semantics. Every sentence adds non-redundant information; there is no filler or repetition of the title.
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 five parameters and no annotations, the description is incomplete: it omits the meaning of pages and out_dir, and does not clarify default output behavior or what happens when overwrite is false and a file exists. The output schema may cover return structure, but the missing parameter and side-effect context leaves an agent under-informed.
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 for missing parameter documentation. It meaningfully explains list_only and overwrite, but pages and out_dir remain unexplained. The description adds value for two of five parameters but does not fully compensate for the schema's lack of 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 names a specific action ('抽取 PDF 内嵌图片') and output format ('PNG'), which clearly identifies the tool's resource and distinguishes it from siblings like tool_extract_text and tool_extract_attachments. Even without explicit sibling naming, 'embedded images' 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?
The description gives clear context for extracting embedded images but does not explicitly state when to prefer this tool over alternatives or when not to use it. The list_only and overwrite hints are parameter-level usage guidance, not tool-selection guidance, so usage remains mostly implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.