List embedded images inside Excel workbooks by scanning the internal media folder. Returns image count, filenames, sizes, and dimensions, ensuring models see visuals that other tools silently drop.
列出工作簿内的嵌图片（零依赖，直接扫描 xl/media/）。
为什么需要它：多数 Excel MCP 会静默丢弃所有内嵌图片， 于是贴在单元格里的流程图/截图永远到不了模型眼前。
返回：图片数量、文件名、大小、尺寸（PNG/JPEG/GIF/BMP 可从文件头解析）。 注意：只返回清单而非图片本体，避免 base64 撑爆上下文； 若需模型"看到"图片内容，请解压后交给多模态模型读取。
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the exact approach (zero dependencies, direct scan of xl/media/), what is returned (image count, filenames, size, dimensions, with header parsing for PNG/JPEG/GIF/BMP), and a deliberate design limitation (returns only a list, not base64 image bodies, to avoid context overflow). This is a transparent and complete behavioral contract.
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 moderately long but every sentence earns its place: core action, rationale, return fields, and caveat. It is front-loaded with the main purpose and uses line breaks to separate sections, making it easy to scan despite its length.
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 listing tool with no output schema, the description covers the essential behavior, return fields, and the key limitation. It lacks error-handling details and explicit file-path expectations, but an agent has enough information to invoke it correctly in the intended workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the sole file_path parameter. It indirectly clarifies that file_path points to a workbook whose xl/media/ folder is scanned, but it never explicitly defines the parameter, accepted file types, or path format. The compensation is partial at best.
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 opens with a specific verb and object ('列出工作簿内的嵌图片' – list embedded images in a workbook) and states the mechanism (scanning xl/media/). It clearly distinguishes this from the sibling tools, which deal with cell data, formatting, or aggregation, making it immediately identifiable as the image-listing tool.
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 explains why this tool exists ('为什么需要它' – because other Excel MCPs silently discard images), which tells the agent when this tool is valuable. It also gives an explicit when-not: if the model needs to see image content, unzip and pass to a multimodal model rather than relying on this tool. It does not name a specific sibling alternative, but the context and exclusion are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.