Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@exif-mcp What camera took the photo at /home/user/vacation.jpg?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that allows LLMs (or humans) to read image metadata on-demand, entirely offline. Based on the excellent exifr library it's exremely fast and does not rely on any external tools.
Usecases:
Analyze image metadata and visualize it
Perform analysis of your image library: what are my most used cameras? Lens distribution? Which dates of the week I take most pictures on? Most favorite locations?
Debugging image manipulation code.
Ths tool is used extensively by the reverse geolocation service PlaceSpotter for development and testing.
exif-mcp is a Model Context Protocol (MCP) server that provides tools for extracting various metadata segments from images. Built with TypeScript, it leverages the excellent exifr library to parse metadata from images in common formats like JPEG, PNG, TIFF, and HEIC. This allows this service to parse image metadata without executing any external tools which allows it to be both highly efficient and secure.
Local operation: Works completely offline with no remote network required
Multiple segments: Extracts EXIF, GPS, XMP, ICC, IPTC, JFIF, and IHDR metadata
Various input formats: Supports JPEG, TIFF, HEIC/AVIF, and PNG
Flexible image sources: Read from file system, URLs, base64 data, or buffers
Specialized tools: Get orientation, rotation info, GPS coordinates, and thumbnails
Related MCP server: llm-vision-mcp
# Clone the repository
git clone https://github.com/stass/exif-mcp.git
cd exif-mcp
# Install dependencies
npm install
# Build the project
npm run buildPut this into Claude config file (claude_desktop_config.json):
"mcpServers": {
"exif-mcp": {
"command": "node",
"args": [
"/path/to/exif-mcp/dist/server.js"
]
}
},Restart Claude. Now you can ask Claude to inspect images for you or e.g. find files taken with specific camera. This works best in combination with filesystem MCP tools so Claude can find files and list directories.
# Start the server
npm start
# For development with auto-reload
npm run devThe server uses the StdioServerTransport from the MCP SDK, making it compatible with any MCP client that supports STDIO transport.
You can use mcp-proxy to enable remote access.
The following tools are provided by the server:
Tool name | Description |
| Reads all or specified metadata segments |
| Reads EXIF data specifically |
| Reads XMP data |
| Reads ICC color profile data |
| Reads IPTC metadata |
| Reads JFIF segment data |
| Reads IHDR segment data |
| Gets image orientation (1-8) |
| Gets rotation and flip information |
| Extracts GPS coordinates |
| Removes all metadata (EXIF/GPS/XMP/ICC/IPTC) losslessly. JPEG & PNG |
| Edits EXIF and GPS fields in a JPEG, returns the modified image |
| Extracts embedded thumbnail |
A built-in web interface — the Metadata Lab — lets you use every feature from any browser without an MCP client:
npm run build
npm run web
# open http://localhost:3000Add WEB_OPEN=1 to auto-open the browser, or change the port with WEB_PORT.
Analyze — drag & drop one or many images (or paste a URL) for instant metadata:
Summary cards (camera, lens, exposure, orientation), a full tag table, and raw JSON export
GPS coordinates with OpenStreetMap / Google Maps links and a one-click copy
Batch mode: every dropped image gets a thumbnail in a filmstrip you can switch between
Edit EXIF — edit camera fields (Make, Model, Software, dates, copyright…), set GPS coordinates, or clear GPS, then download a modified copy. The original file is never touched.
Clean — remove all metadata (EXIF, GPS, XMP, ICC, IPTC) from JPEG/PNG with one click. Lossless: only metadata segments are stripped, pixels are untouched.
The web server exposes a JSON API as well:
curl -X POST http://localhost:3000/api/analyze \
-H 'Content-Type: application/json' \
-d '{"image":{"kind":"path","path":"/path/to/photo.jpg"}}'
curl -X POST http://localhost:3000/api/strip \
-H 'Content-Type: application/json' \
-d '{"image":{"kind":"path","path":"/path/to/photo.jpg"}}'
curl -X POST http://localhost:3000/api/edit \
-H 'Content-Type: application/json' \
-d '{"image":{"kind":"base64","data":"..."},"fields":{"Make":"My Camera"},"gps":{"latitude":40.71,"longitude":-74.0}}'Image sources match the MCP tool format (path, url, base64, buffer).
Start the inspector: npx @modelcontextprotocol/inspector node dist/server.js
Connect to it with MCP Inspector using the STDIO transport
Call a tool, e.g., read-metadata with parameter:
{
"image": {
"kind": "path",
"path": "/path/to/image.jpg"
}
}You cal also use MCP inspector command line like this: npx @modelcontextprotocol/inspector --cli node dist/server.js --method tools/call --tool-name read-exif --tool-arg image='{"kind": "path", "path": "/path/to/image.jpeg"}' --tool-arg pick="[]"
The server supports multiple ways to provide image data:
// From local file system
{
"kind": "path",
"path": "/path/to/image.jpg"
}
// From URL (http, https, or file://)
{
"kind": "url",
"url": "https://example.com/image.jpg"
}
// From base64 data (raw or data URI)
{
"kind": "base64",
"data": "data:image/jpeg;base64,/9j/4AAQSkZ..."
}
// From base64 buffer
{
"kind": "buffer",
"buffer": "/9j/4AAQSkZ..."
}# Run tests
npm test
# Run tests with watch mode
npm run test:watchexif-mcp/
├── src/
│ ├── server.ts # Main MCP entry point
│ ├── tools/
│ │ ├── index.ts # Tool registration
│ │ ├── loaders.ts # Image loading utilities
│ │ └── segments.ts # exifr options builders
│ ├── web/
│ │ ├── server.ts # Browser web server (API + static UI)
│ │ ├── image.ts # Format detection, JPEG/PNG metadata stripping
│ │ └── edit.ts # EXIF/GPS editing (piexifjs)
│ └── types/
│ └── image.ts # Type definitions
├── web/
│ └── index.html # Metadata Lab browser UI
├── tests/ # Test files
└── README.mdThe server provides standardized error handling for common issues:
Unsupported formats or missing metadata
Network fetch failures
Oversized payloads
Internal exifr errors
BSD 2-clause
exifr - Extremely fast and robust EXIF parsing library
Edit EXIF and GPS fields in a JPEG image. Returns the modified image as a base64 data URL.
| Name | Required | Description | Default |
|---|---|---|---|
| gps | No | ||
| image | Yes | ||
| fields | No | ||
| clearGps | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states that the tool edits fields and returns a modified image, but does not explain whether the original input is mutated in place, how existing metadata is handled, or whether the tool overwrites or preserves unspecified fields. It also omits any side effects or prerequisites (e.g., file permissions).
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, concise sentence that directly states the tool's action and return value. There is no redundant or filler content; every word earns its place.
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?
Given the tool's complexity (4 parameters, nested objects, no annotations, no output schema), the description is too sparse. It fails to mention the required 'image' parameter, how to provide the image (path/url/base64/buffer), the existence of 'clearGps', or the meaning of the various EXIF fields. The agent would need to rely entirely on the schema without additional guidance.
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%, and the description does not compensate. It mentions 'EXIF and GPS fields' but does not map this to the specific 'fields', 'gps', or 'clearGps' parameters. The schema provides structure (e.g., image kind, field names) but the description adds no explanation of how to use these parameters, their formats, or relationships.
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 ('Edit') and identifies the resource ('EXIF and GPS fields in a JPEG image'). It clearly distinguishes from the sibling read-only tools like read-exif and read-metadata by indicating a modification operation. The return format (base64 data URL) is also stated, making the purpose 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 clearly states the tool's purpose, which is to edit EXIF and GPS fields. It doesn't explicitly mention alternatives or exclusions, but the sibling tool names (read-exif, strip-metadata, etc.) make it obvious when this tool should be used versus read-only or stripping tools. The context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract GPS coordinates (latitude/longitude) from image metadata
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states the action and target, but does not explain output format, behavior when no GPS data exists, or any side effects. For a read-only extraction tool, this is a minimal disclosure.
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, direct sentence with no filler. It front-loads the purpose and avoids redundancy with the schema.
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 has a nested object schema, no annotations, and no output schema. The description provides minimal context about input requirements or return value. Given the complexity of the image parameter and the lack of annotation support, the description is not complete enough for an agent to invoke reliably.
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?
The schema provides an 'image' object with properties (url, data, kind, path, buffer) but zero description coverage. The tool description adds only that the image is a source of metadata, without explaining the accepted input formats or how to specify the image. This is insufficient compensation for the 0% schema coverage.
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 explicitly states the tool extracts GPS coordinates (latitude/longitude) from image metadata. The verb 'Extract' and the specific resource (GPS coordinates) clearly distinguishes it from sibling tools like read-exif or read-metadata which target broader metadata.
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?
No guidance on when to use this tool compared to read-exif or read-metadata. The description does not mention alternatives, exclusions, or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get image orientation value (1-8)
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It reveals only the return value range (1-8) but fails to mention how missing orientation values are handled, whether errors occur for invalid images, or any side effects (despite it being a read operation).
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, concise sentence with no redundant words. It delivers the core function and the expected output range with maximum efficiency.
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 description gives the essential purpose but lacks detail on edge cases (e.g., no orientation present) and does not address the parameter meaning. For a simple getter, it is minimally sufficient, but it does not fully cover the tool's behavior beyond the bare minimum.
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?
The description provides no information about the 'image' parameter beyond the schema's structure. With 0% schema description coverage, the description should compensate, but it does not explain how to specify the image source or clarify the nested object properties.
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 clearly states the tool's function: retrieving the image orientation value with a specific numeric range (1-8). It distinguishes itself from sibling metadata tools by focusing on the orientation value specifically, making its purpose 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?
No explicit guidance on when to use this tool versus alternatives like read-exif or read-metadata is provided. The usage is implied: use it when you need only the orientation value, but the description does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read EXIF data from an image with optional tag filtering
| Name | Required | Description | Default |
|---|---|---|---|
| pick | No | ||
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does communicate that the operation is read-only (no side effects) and that tag filtering is optional. However, it omits details about return format, error handling, or any constraints on image input (e.g., supported file types). For a simple read tool, this is adequate but not rich.
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 that starts with the concrete verb 'Read' and includes the essential qualifier about tag filtering. It is concise without unnecessary words, making it easy to parse and remember. All content is relevant to the tool's function.
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 has a non-trivial parameter structure (nested image object with multiple input types) and no output schema, yet the description does not explain how to specify the image or what the return value looks like. It also does not position the tool against its siblings beyond the EXIF scope. For the complexity level, this description is under-specified.
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 parameter documentation. It mentions 'optional tag filtering', which clearly maps to the 'pick' parameter, but it provides no explanation of the 'image' parameter, which is a complex nested object with multiple input kinds (path, url, base64, buffer). The description leaves the agent to infer the image parameter's structure entirely from the schema, which lacks 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 clearly states a specific action ('Read EXIF data') and a specific resource ('from an image'), with the additional qualifier 'optional tag filtering' that distinguishes it from sibling tools like read-metadata, read-xmp, and read-icc. This makes the tool's purpose unmistakable.
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 provides no guidance on when to use this tool versus alternatives, such as read-metadata for broader metadata or edit-exif for modifying data. It does not mention any exclusions, prerequisites, or alternative tool names. The only contextual hint is 'optional tag filtering', but it does not explain when such filtering is beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read ICC metadata from an image
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'Read ICC metadata' without explaining return format, error behavior, or whether the image is left unchanged. The reading action implies non-destructive behavior, but this is not explicit.
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, direct sentence with no redundancy, making it easy to parse and front-loaded with the key action. However, it is under-sized, lacking any supporting context, which prevents a perfect score.
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 has a nested input schema and no output schema, but the description does not explain what ICC metadata is, what the output will be, or any edge cases. It provides only the bare minimum to convey the core function, which is insufficient for an agent to use confidently.
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% and the description adds no parameter information. The one required parameter 'image' is an object with a 'kind' enum, but the description does not explain how to choose the kind or how url/data/path/buffer relate, leaving the agent without essential usage details.
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 starts with a specific verb 'Read' and a specific resource 'ICC metadata' from an image. The 'ICC' qualifier clearly distinguishes it from sibling tools like read-exif and read-xmp, making the purpose 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 provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or explicit comparisons to sibling metadata readers, leaving the agent to infer applicability solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read IHDR metadata from an image
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only states the read operation, with no mention of return format, error handling, or limitations (e.g., PNG-only requirement). This is a significant gap for an agent selecting the tool without external context.
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, front-loaded sentence that conveys the core action and target with no unnecessary words. It is appropriately concise for a simple read operation, though it sacrifices informational depth.
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?
With no annotations, no output schema, and a single nested parameter, the description is too terse. It doesn't specify what IHDR metadata includes (width, height, bit depth, etc.) or what the tool returns, leaving the agent without sufficient context to anticipate the outcome.
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%, and the description does not compensate. It does not explain how the 'image' parameter should be structured (e.g., path, URL, base64, buffer) or what the enum 'kind' values mean. The description adds no value beyond the schema's property names.
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 'Read IHDR metadata from an image' uses a specific verb ('Read') and resource ('IHDR metadata'), clearly distinguishing it from sibling metadata readers like read-exif or read-xmp. The IHDR term is a well-known PNG header chunk, so the purpose 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 no explicit guidance on when to use this tool versus alternatives, nor does it mention conditions or exclusions. However, the use of 'IHDR' in the name implies usage when IHDR-specific metadata is needed, providing an implicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read IPTC metadata from an image
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for behavioral disclosure. It only says 'read,' implying a read-only operation, but provides no details about how different input kinds (URL, buffer, path) are handled, potential network requirements, or failure behaviors.
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, direct sentence with no redundant information. It is appropriately front-loaded and concise, containing only the core message.
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 lacks an output schema and lives among many similar metadata readers. The description does not specify return format, behavior when no IPTC data exists, or how the image input is consumed. This under-specification leaves critical gaps for an agent selecting and invoking the tool.
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%—the description adds no meaning to the 'image' parameter. While the schema itself is structurally clear with named sub-fields (url, data, path, buffer) and a kind enum, the description does not help an agent understand the intended input semantics. For low coverage, compensation is required but absent.
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 clearly states the tool's function with a specific verb and resource: 'Read IPTC metadata from an image.' This distinguishes it from sibling tools like read-exif and read-xmp, which target other metadata formats. No ambiguity exists.
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?
No guidance is provided on when to use this tool versus alternatives such as read-metadata or read-exif. With a large set of sibling metadata readers, explicit usage context is essential but entirely missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read JFIF metadata from an image
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it only says 'read'. It doesn't mention return format, error handling, or what happens if JFIF metadata is absent. The read verb implies non-destructive, but that's not fully disclosed.
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 short sentence with no filler. It is front-loaded and efficient, though it sacrifices depth for brevity.
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?
Given no annotations and no output schema, the description should explain what is returned and how inputs are used. It omits this, making the tool feel incomplete for an agent trying to invoke it correctly.
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?
The schema defines an 'image' object with kind and optional url/data/path/buffer, but has zero descriptions. The description adds no information about how to choose a kind or format the input, failing to compensate for the schema's lack of explanations.
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 'Read JFIF metadata from an image' clearly states the action (read) and the specific resource (JFIF metadata), distinguishing it from sibling tools like read-exif and read-xmp. However, it doesn't explicitly call out the distinction, so it stops short of a full 5.
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 use this tool versus alternatives like read-metadata or read-exif. The description only states the function, leaving the agent to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read all or specified metadata segments from an image
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | ||
| segments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a read-only operation but does not mention return format, error behavior when a segment is missing, or any limits on image formats. The behavior beyond 'read' is completely unspecified.
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, but it is under-specified. While concise, it does not enough cover the tool's complexity (2 parameters, nested image object). The structure is fine, but the brevity comes at the cost of 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?
Given the tool has 2 parameters, one complex nested object, no annotations, and no output schema, the description is grossly incomplete. It provides no information about how to pass the image, what segments are supported, or what the return value looks like. The tool is not usable from this description alone.
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%. The description only hints at the 'segments' parameter through 'all or specified metadata segments'. It says nothing about the required 'image' parameter, which has a complex nested object structure (kind, url, data, path, buffer). The description fails to add any meaning to the schema beyond a vague hint.
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 clearly states the verb 'read', the resource 'metadata segments', and the scope 'all or specified'. This distinguishes it from sibling tools that target specific segment readers (read-exif, read-xmp), as it can read all at once or a specified subset.
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 implies when to use this tool: when you need to read all or a selection of metadata segments. However, it does not explicitly name alternatives or state when to prefer the segment-specific sibling tools, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read XMP metadata from an image with option for extended XMP segments
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | ||
| extended | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the action and the extended option but does not explain what happens if no XMP metadata exists, what output format to expect, or any side effects. This is insufficient for a tool with no annotation support.
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 concise sentence with no redundant or filler content. It immediately communicates the core purpose and the key option, making it easy to parse.
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?
This is a simple read tool with only two parameters, so a short description might suffice. However, it lacks context on the extended XMP feature, error behavior, or return value expectations. Given no output schema and no annotations, more detail would help complete the picture for an agent.
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?
The schema has 0% description coverage, so the description must compensate. It does clarify the 'extended' boolean by mentioning 'option for extended XMP segments', but the 'image' parameter is only loosely referenced as 'from an image' with no functional detail. The schema itself provides structure, but the description adds minimal insight beyond the extended flag.
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 'Read' and resource 'XMP metadata', clearly distinguishing it from sibling tools like read-exif and read-iptc by naming XMP explicitly. It also mentions the extended XMP option, adding scope.
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 implied by the description and tool name—one would use this when needing XMP metadata—but there is no explicit guidance on when to choose this over read-metadata or other sibling tools, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed rotation and flip information from image orientation
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden. The verb 'Get' implies a non-destructive read operation, but the description does not disclose return format, side effects, or any exceptional behavior. It adds context about the focus on rotation/flip but lacks deeper behavioral details.
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 redundant words. It is front-loaded with the action 'Get' and clearly states the resource, making it concise and well-structured.
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 description gives the core function but lacks context about return values (since no output schema exists) and differentiation from the sibling 'orientation' tool. For a simple getter, it is minimally adequate but does not fully inform the agent about what to expect or when to choose it.
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?
The input schema describes a single nested 'image' object with kind, url, data, path, and buffer, which is fairly self-explanatory. The description adds that the tool derives info from 'image orientation', but does not explain parameter usage or format details. Schema coverage is 0%, but the schema itself provides structural semantics, so the slight clarification in the description justifies a 3.
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 'Get' and a clear resource 'detailed rotation and flip information', which states what the tool does. It distinguishes itself from the sibling 'orientation' by specifying 'detailed rotation and flip', but does not explicitly name that sibling as an alternative.
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 no guidance on when to use this tool versus alternatives. It simply states the function, leaving it to the agent to infer that this is for rotation/flip info, without mentioning exclusions or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove all metadata (EXIF, GPS, XMP, ICC, IPTC) from an image losslessly. Supports JPEG and PNG.
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that stripping is lossless and removes specific metadata categories, which is useful. However, it does not state whether the operation modifies the original file or returns a new image, nor what happens for unsupported formats. With no annotations, this leaves key behavioral 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?
One compact sentence that conveys the action, scope, lossless nature, and supported formats. Every word adds information with no fluff.
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 mutation tool with no output schema and no annotations, the description should explain what the output is (e.g., whether it returns a stripped image or modifies in place). It is missing this critical context, making it incomplete for an agent to utilize correctly.
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?
The only parameter is 'image', but the description merely refers to 'an image' without explaining how to specify it (path, URL, base64, etc.). Schema coverage is 0%, so the description should compensate, but it does not add value beyond the schema.
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 clearly states the action ('Remove all metadata') and specifies the metadata types (EXIF, GPS, XMP, ICC, IPTC) and supported formats (JPEG, PNG). This differentiates it from sibling read/edit tools by emphasizing complete removal.
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 implies use when stripping metadata from JPEG/PNG images, but does not explicitly state when to prefer this over siblings like edit-exif or when not to use (e.g., for selective metadata editing). No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract embedded thumbnail from image as base64 data or URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| image | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It states that the tool extracts a thumbnail, which is a read operation, but it does not mention failure modes (e.g., what happens if no thumbnail exists), whether it returns the first/largest thumbnail, or any rate limits or permission requirements. This leaves significant behavioral uncertainty.
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, clear sentence with no filler words. It is concise and front-loads the core action (extract thumbnail) and output format, though it could benefit from a brief note about the input parameter to be more structured.
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?
Given the tool has two parameters (one nested), no output schema, and no annotations, the description is too sparse to be complete. It does not explain the return value structure, error handling (e.g., missing thumbnail), or how to choose among the image kind options. The sibling tools all operate on image metadata, and this description does not help the agent understand how this extraction fits into a 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 must compensate for parameter meaning. It hints at the 'url' boolean by mentioning 'base64 data or URL', but it does not explain the 'image' object structure, its 'kind' enum, or how to specify the source image. The schema field names are self-explanatory but the description adds minimal clarification beyond them.
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 ('Extract') with a clear resource ('embedded thumbnail') and output format ('as base64 data or URL'). This clearly distinguishes it from sibling metadata readers like read-metadata or read-exif, which focus on metadata fields rather than extracting image data.
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 implies usage when an embedded thumbnail is needed, but does not explicitly state when to use this tool versus the sibling metadata tools, nor does it mention any exclusions or alternatives. It provides no direct comparison or guidance for selecting between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0edit-exifgps-coordinatesorientationread-exifread-iccread-ihdrread-iptcread-jfifread-metadataread-xmprotation-infostrip-metadatathumbnailThe read-metadata tool overlaps with the specific read-exif/read-xmp/read-icc/read-iptc readers, since all can retrieve metadata segments. Orientation and rotation-info also cover closely related concepts, which could cause misselection. Otherwise, most tools have distinct purposes.
There is a coherent read-* prefix for seven tools, but naming style shifts for others such as orientation, rotation-info, gps-coordinates, strip-metadata, edit-exif, and thumbnail. The mixed noun and verb patterns are readable but not fully consistent.
With 13 tools, the server is well-scoped for an EXIF/metadata-focused utility. Each tool has a meaningful role in reading, editing, stripping, or extracting metadata, and the count is within the ideal range.
The tool set covers reading all major metadata formats, editing EXIF/GPS, removing all metadata, and extracting thumbnails. The main gap is editing non-EXIF metadata formats like XMP or ICC, but core workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Qwen Image 3 AI image generation
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP server for NanoBanana AI image generation and editing
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/myworkgmail001-sketch/exif-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
