get_image_metadataInspect image metadata—resolution, megapixels, aspect ratio, file size, color space, and 300 DPI print sizing—to assess print viability.
Retrieve comprehensive image metadata including resolution, megapixels, aspect ratio, file size, color space, and print sizing at 300 DPI.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | Path to the image file to inspect. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden; 'Retrieve' implies a read-only, non-destructive operation and the mention of print sizing at 300 DPI hints at derived rather than stored values. It does not state behavior for missing/unsupported files, accepted formats, or whether files are modified — modest gaps for a simple read tool with an output schema.
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, and the field enumeration is informative rather than redundant. Slightly list-heavy, but nothing needs trimming.
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 simple (one required path parameter) and has an output schema, so return values need not be restated. The description is sufficient for correct invocation; only minor behavioral details (formats, error cases) are absent.
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?
Only one parameter, and schema coverage is 100% with a clear description ('Path to the image file to inspect'), so the schema does the work. The description adds nothing about path form (relative vs absolute) or supported image extensions, so baseline 3 applies.
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 uses a specific verb and resource ('Retrieve comprehensive image metadata') and enumerates the returned fields (resolution, megapixels, aspect ratio, file size, color space, print sizing). This clearly separates it from mutation siblings like upscale_image, though it never explicitly distinguishes itself from calculate_print_dpi, whose DPI/print-sizing territory it partially overlaps.
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 by the name and the 'inspect an image file' framing; there is no explicit when-to-use statement, no exclusions, and no pointer to calculate_print_dpi for dedicated print-DPI computation. An agent can infer the context but must reason about the overlap itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.