Inspect and strip EXIF, XMP, IPTC, C2PA, PDF info, and Word properties.
Scored across 2 tools
The two tools have clearly distinct purposes: inspect_metadata reads metadata, while strip_metadata removes it. There is no overlap or ambiguity in their intended use.
Both tools follow a consistent snake_case verb_noun pattern (inspect_metadata, strip_metadata), making the set predictable and easy to navigate.
With only 2 tools, the set is on the thin side for a metadata processing server, though each tool is essential and non-redundant. It covers the core workflow but could benefit from additional operations like batch processing or format-specific handling.
The tools cover inspection and removal for common image and document formats (JPEG, PNG, WebP, PDF, DOCX) with mode options, but minor gaps exist such as batch processing or support for additional metadata-rich formats.
Read EXIF, XMP, IPTC, C2PA, and AI-generation markers from a JPEG, PNG, or WebP. Also reads a PDF info dictionary and XMP, or Word core and app properties. Pass a public file_url or file_base64.
| Name | Required | Description | Default |
|---|---|---|---|
| file_url | No | Public http or https URL of a JPEG, PNG, WebP, PDF, or DOCX file. | |
| filename | No | Original file name, used in the report. | |
| file_base64 | No | Base64-encoded file bytes. A data URL is accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing the extraction surface (C2PA/AI-generation markers, PDF info dictionary, Word core/app properties), which tells the agent exactly what signals it will get back.
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?
Two sentences, zero filler. The capability set is front-loaded in the first sentence and the input instruction is isolated in the second, making it easy to scan.
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?
No output schema exists, so the description carries some burden for return values; it names what is read ('the report' is referenced only obliquely) but not the shape of the result. For a read-only, open-world inspection tool whose annotations cover safety, this is nearly complete but leaves output structure unstated.
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 100%, so all three parameters are already documented, including the 'public URL' constraint that the description repeats. The description adds no format, size, or mutual-exclusivity detail beyond the schema, 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?
States a specific verb ('Read') and enumerates the exact metadata standards extracted (EXIF, XMP, IPTC, C2PA, AI-generation markers) plus the supported containers (JPEG/PNG/WebP/PDF/DOCX). This is highly specific, but it never names or contrasts with its sibling strip_metadata, so the read-vs-removal distinction must be inferred.
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 closing sentence gives input guidance ('Pass a public file_url or file_base64'), which implicitly tells the agent the two accepted input modes. However there is no explicit when-to-use context, no mention of prerequisites, and no routing against strip_metadata, leaving usage only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a cleaned JPEG, PNG, WebP, PDF, or DOCX as base64, plus the fields that were removed. Image mode ai_only keeps camera EXIF and GPS. Mode all removes them too. PDF and Word files drop document properties in either mode.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ai_only removes AI-generation and C2PA markers from an image and leaves camera EXIF and GPS. all also removes EXIF, GPS, XMP, and IPTC. PDF and Word files drop document properties in either mode. Default: all. | |
| file_url | No | Public http or https URL of a JPEG, PNG, WebP, PDF, or DOCX file. | |
| filename | No | Original file name, used in the report. | |
| file_base64 | No | Base64-encoded file bytes. A data URL is accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, but the description goes further by disclosing what each mode actually removes (AI/C2PA markers vs EXIF/GPS/XMP/IPTC), that PDF/Word property handling is mode-independent, and that the response contains both the cleaned file and the removed fields. It does not discuss size limits, auth, or whether the original is untouched, keeping it below a 5.
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?
Four short sentences, front-loaded with the return payload ('Return a cleaned JPEG ... as base64, plus the fields that were removed'), followed by mode behavior. Efficient overall, though the mode detail duplicates the schema wording rather than adding new information.
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 output schema, the description correctly explains the return shape (base64 cleaned file plus removed fields), which is the key gap it needed to fill. Input-source exclusivity (file_url vs file_base64) is left entirely to the schema, but nothing critical for a correct call is missing.
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 100%, so the schema already documents every parameter thoroughly. The description's mode sentences largely restate the enum documentation already present in the schema (including the 'Default: all' and PDF/Word behavior), adding little new parameter meaning. 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?
States a specific verb and resource ('Return a cleaned ... plus the fields that were removed') and enumerates supported formats (JPEG, PNG, WebP, PDF, DOCX). An agent immediately knows this transforms a file and reports removals. It does not explicitly name or contrast with the sibling inspect_metadata, so it falls short of a 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?
Mode semantics ('ai_only keeps camera EXIF and GPS', 'all removes them too') give real usage context, but there is no guidance on when to pick this tool over inspect_metadata, nor any note that exactly one of file_url/file_base64 should be supplied. Usage is implied rather than stated.
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.
inspect_metadatastrip_metadataRemove GPS, device details, dates and AI labels from video, PDF, RAW and photo files.
Inspect and remove PDF/DOCX author metadata and comments; approve tracked changes before cleaning.
Inspect and remove C2PA content credentials from AI-generated images, video and audio. Free, no key.
Remove EXIF, GPS location and camera serials from images without re-encoding the pixels
Add one secure layer between your agents and this server.