Extract width, height, format, mode, file size, and capped EXIF tags from a local image file to inspect metadata before conversion or editing.
Image metadata: width, height, format, mode, file size, and EXIF tags (capped).
| Name | Required | Description | Default |
|---|---|---|---|
| input_path | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| exif | No | Up to 50 EXIF tags; values cut at 200 characters. | |
| mode | Yes | ||
| width | Yes | ||
| format | Yes | ||
| height | Yes | ||
| file_bytes | Yes | ||
| exif_truncated | No |
Changes observed during successful MCP inspections.
v0.3.0Does 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.