tool_extract_attachmentsExtract embedded file attachments from a PDF into a target directory. Enable overwrite to replace existing files with the same name.
抽取 PDF 内嵌附件文件到指定目录；overwrite=true 才允许覆盖同名文件。
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| out_dir | 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?
Without annotations, the description carries the full burden. It does disclose a key behavioral trait: overwrite=true is required to overwrite existing files, which is useful. However, it does not explain other behaviors such as out_dir default handling, directory creation, or whether the source PDF is 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?
The description is a single sentence with no filler, front-loading the core action before the overwrite condition. Every part adds value, and it is appropriately sized for a tool with only three parameters.
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 tool is relatively simple and has an output schema, so return-value details are not required. Still, the absence of explanation for out_dir's default behavior and the role of 'path' leaves minor gaps that matter for correct invocation, especially with no annotations to fill them.
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 adds meaning for 'out_dir' via '指定目录' and clarifies the overwrite semantics. However, it does not explain the meaning of the required 'path' parameter or what happens when out_dir is null.
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 ('extract PDF embedded attachment files') and a target resource, clearly distinguishing it from sibling tools like extract_images or extract_text. The phrase 'PDF 内嵌附件文件' precisely identifies what is being extracted.
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 does not provide explicit guidance on when to use this tool versus alternatives such as tool_extract_images or tool_extract_text. The intended use case is implied by the purpose, but no exclusions, preconditions, or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.