Skip to main content
Glama
Sign In
strip-ai-metadata-mcp

strip-ai-metadata-mcp

by onsecrethunt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Remove metadata from files

clean_files

Remove hidden GPS, EXIF, C2PA credentials and AI prompts from photos, videos, PDFs and RAW files locally, saving clean copies while leaving the originals unchanged.

Instructions

Removes hidden metadata from photos (JPG, PNG, WebP, AVIF, HEIC), videos (MP4, MOV), PDFs and camera RAW files (CR2, CR3, NEF, ARW, DNG, RAF, RW2, ORF, PEF): GPS location, camera and serial numbers, owner and author names, dates, XMP/IPTC, C2PA Content Credentials and AI prompts. Works on files or folders on this computer. Originals are not changed: a clean copy is saved as name-clean.ext unless in_place is true. Runs locally; nothing is uploaded.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "paths": "<paths>"
    },
    "name": "clean_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoImages: all = remove everything (default); ai = only AI tags, C2PA and prompts, keep camera data; gps = only location; c2pa = only Content Credentials. Videos support all and gps.
pathsYesAbsolute paths of files or folders to clean
in_placeNoOverwrite the originals. Only use when the user explicitly asks for it.
recursiveNoInclude sub-folders when a folder is given.
keep_datesNoRAW files: keep the capture date.
output_dirNoFolder to save clean copies in. Default: next to each original.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare openWorldHint=false and destructiveHint=false; the description goes further by stating that originals are unchanged by default, that a copy is written as name-clean.ext, and that processing is fully local with nothing uploaded. The in_place exception is disclosed as an overwrite, so the annotation is not contradicted. It stops short of describing runtime behavior such as progress, partial failures, or what happens when a file cannot be parsed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The default behavior (copy, not overwrite) is front-loaded in the second half and the format enumeration is compacted into a single sentence. The long list of RAW extensions consumes space without changing agent behavior, but the overall length is defensible for a multi-format tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining the result, and it does so via the name-clean.ext convention and the in_place exception. It omits what the call returns (counts, per-file status, errors), which is the main remaining gap for a batch file operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains mode, paths, in_place, recursive, keep_dates, and output_dir. The description adds only the output filename convention (name-clean.ext), which is meaningful but limited; the enum semantics for mode are carried entirely by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ("Removes") and resource ("hidden metadata") and enumerates the exact file types and metadata categories affected (GPS, serials, XMP/IPTC, C2PA, AI prompts). It is unambiguous about what the tool does, but never references the sibling inspect_files, so an agent gets no explicit routing signal between cleaning and inspecting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than stated: it works on local files or folders, and in_place carries the guardrail "only use when the user explicitly asks for it." There is no explicit when-to-use or when-not-to-use guidance relative to inspect_files, and no guidance on when to prefer one mode over another beyond the mode enum's own text.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools