Skip to main content
Glama
deenesjakoruzh
nextframedev

EXIF MCP Server

by nextframedev
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

EXIF MCP Server

Inspect and remove EXIF metadata locally through MCP tools.

This project is a stdio-first Python MCP server for reading EXIF metadata, detecting GPS/location fields, summarizing privacy-sensitive metadata, and writing cleaned image copies with full or selective EXIF removal for supported formats.

What This Project Does

The server exposes eleven MCP tools for local image paths:

  • inspect_exif

  • inspect_exif_detailed

  • has_gps_exif

  • find_images_with_gps_exif

  • find_images_with_exif_fields

  • summarize_exif_privacy

  • strip_exif

  • strip_selected_exif_fields

  • batch_strip_exif

  • batch_strip_gps_exif

  • batch_strip_selected_exif_fields

It also exposes two MCP resources and two MCP prompts:

  • resources:

    • exif://privacy-guide

    • exif://supported-formats

  • prompts:

    • review-photo-privacy

    • clean-photos-for-sharing

It is designed for AI clients and agent workflows, and this repository is focused on the MCP server itself.

Related MCP server: EXIF Extractor MCP Server

Project Shape

This repository is MCP-first:

  • the shared EXIF logic lives under src/exif_mcp_server/core/

  • the MCP adapter lives under src/exif_mcp_server/tools/, resources/, and prompts/

  • tests, examples, and docs are included so the project can work as a sample MCP server for learning and reuse

Supported Formats

Current v1 support is intentionally narrow:

  • .jpg

  • .jpeg

  • .png

  • .webp

  • .tif

  • .tiff

Do not assume IPTC or XMP support in this MCP server.

Install

Requirements:

  • Python 3.11+

Set up a local virtual environment and install dependencies:

python3 -m venv .venv
source .venv/bin/activate
pip install -e '.[dev]'

Why quote '.[dev]': Some shells such as zsh treat brackets as glob patterns.

Run Tests

Run the full test suite:

pytest

Run one focused test file:

pytest tests/test_inspect.py
pytest tests/test_privacy.py
pytest tests/test_clean.py
pytest tests/test_batch.py

The repo also includes manual-test sample images in examples/sample_images/.

Lint And Type Check

Run Ruff:

ruff check .

Run mypy against the typed source tree:

mypy

The current mypy configuration checks src/ and ignores missing type stubs for piexif, which does not ship typed metadata.

Continuous Integration

Use the same core verification steps before publishing changes:

  • ruff check .

  • mypy

  • pytest

Run The Server

Start the MCP server over stdio:

python -m exif_mcp_server.server

Or use the installed console entrypoint:

exif-mcp-server

The server will appear idle in the terminal because it is waiting for an MCP client over stdio.

The default transport is still stdio. Remote transport is now optional and must be selected explicitly.

Remote Transport

The server can now run with:

  • stdio

  • streamable-http

  • sse

Recommended remote transport:

  • streamable-http

Streamable HTTP

Run the server over Streamable HTTP on 127.0.0.1:8001:

python -m exif_mcp_server.server --transport streamable-http

Choose a custom host, port, and endpoint path:

python -m exif_mcp_server.server \
  --transport streamable-http \
  --host 0.0.0.0 \
  --port 9000 \
  --streamable-http-path /mcp

Useful optional flags:

  • --json-response

  • --stateless-http

Equivalent environment variables:

  • EXIF_MCP_TRANSPORT=streamable-http

  • EXIF_MCP_HOST=0.0.0.0

  • EXIF_MCP_PORT=9000

  • EXIF_MCP_STREAMABLE_HTTP_PATH=/mcp

  • EXIF_MCP_JSON_RESPONSE=true

  • EXIF_MCP_STATELESS_HTTP=true

SSE

Run the server over SSE:

python -m exif_mcp_server.server --transport sse

Customize host, port, mount path, and SSE endpoint paths:

python -m exif_mcp_server.server \
  --transport sse \
  --host 0.0.0.0 \
  --port 9001 \
  --mount-path /github \
  --sse-path /events \
  --message-path /messages/

Equivalent environment variables:

  • EXIF_MCP_TRANSPORT=sse

  • EXIF_MCP_HOST=0.0.0.0

  • EXIF_MCP_PORT=9001

  • EXIF_MCP_MOUNT_PATH=/github

  • EXIF_MCP_SSE_PATH=/events

  • EXIF_MCP_MESSAGE_PATH=/messages/

Smoke Test

Quickly verify that the server can be created:

python -c "from exif_mcp_server.server import create_server; print(type(create_server()).__name__)"

Expected output:

FastMCP

MCP Inspector

This project is stdio-first. To test it in an MCP Inspector or another local MCP client, configure a stdio server with:

  • command: .venv/bin/python

  • args: -m exif_mcp_server.server

  • working directory: this repo root

If your MCP client expects the installed entrypoint instead, you can use:

  • command: .venv/bin/exif-mcp-server

For a remote client that supports Streamable HTTP, run:

python -m exif_mcp_server.server --transport streamable-http --host 127.0.0.1 --port 8001

Then connect the client to:

http://127.0.0.1:8001/mcp

Expected tools:

  • inspect_exif

  • inspect_exif_detailed

  • has_gps_exif

  • find_images_with_gps_exif

  • find_images_with_exif_fields

  • summarize_exif_privacy

  • strip_exif

  • strip_selected_exif_fields

  • batch_strip_exif

  • batch_strip_gps_exif

  • batch_strip_selected_exif_fields

Expected resources:

  • exif://privacy-guide

  • exif://supported-formats

Expected prompts:

  • review-photo-privacy

  • clean-photos-for-sharing

Client Examples

The exact configuration shape depends on the MCP client. The examples below were checked against the official client docs on April 18, 2026.

Which Client To Use

Client

Best for

Local stdio

Remote HTTP

Notes

Claude Code

terminal-first MCP workflows

yes

yes

best fit if you want quick local testing and CLI management

VS Code

editor-integrated development

yes

yes

good default if you want MCP tools inside a coding workspace

Cursor

editor-integrated AI workflows

yes

yes

good fit if your main coding flow already lives in Cursor

MCP Inspector

debugging and manual verification

yes

yes

best choice for checking raw tool/resource/prompt behavior

Claude Desktop

end-user desktop app workflows

limited

yes

local setup now centers on desktop extensions rather than raw stdio config

Recommended starting points:

  • use MCP Inspector for the first manual smoke test

  • use Claude Code if you want the fastest terminal-based setup

  • use VS Code or Cursor if you want the server available inside your editor

  • use streamable-http when you want one running server shared by multiple clients

Claude Code

Add the local stdio server:

claude mcp add --transport stdio exif-mcp -- \
  /absolute/path/to/image-mcp-server/.venv/bin/python \
  -m exif_mcp_server.server

Add the remote Streamable HTTP server:

claude mcp add --transport http exif-mcp-http \
  http://127.0.0.1:8001/mcp

If you want to use remote transport first, start the server separately:

python -m exif_mcp_server.server \
  --transport streamable-http \
  --host 127.0.0.1 \
  --port 8001

Useful Claude Code commands:

  • claude mcp list

  • claude mcp get exif-mcp

  • /mcp

VS Code

VS Code uses mcp.json with a "servers" object. For a workspace-local setup, create .vscode/mcp.json with:

{
  "servers": {
    "exif-mcp": {
      "command": "/absolute/path/to/image-mcp-server/.venv/bin/python",
      "args": ["-m", "exif_mcp_server.server"]
    }
  }
}

For remote Streamable HTTP, use:

{
  "servers": {
    "exif-mcp-http": {
      "type": "http",
      "url": "http://127.0.0.1:8001/mcp"
    }
  }
}

Notes:

  • workspace config lives in .vscode/mcp.json

  • user-level config is available via MCP: Open User Configuration

  • VS Code also supports auto-discovery from other apps such as Claude Desktop

Cursor

Cursor uses .cursor/mcp.json in the project, or ~/.cursor/mcp.json globally, with an "mcpServers" object.

Project-local stdio example:

{
  "mcpServers": {
    "exif-mcp": {
      "type": "stdio",
      "command": "/absolute/path/to/image-mcp-server/.venv/bin/python",
      "args": ["-m", "exif_mcp_server.server"]
    }
  }
}

Cursor's docs also support remote MCP configuration with fields such as url and headers. For this server, the remote endpoint is:

http://127.0.0.1:8001/mcp

MCP Inspector

For a local stdio session:

npx @modelcontextprotocol/inspector \
  /absolute/path/to/image-mcp-server/.venv/bin/python \
  -m exif_mcp_server.server

For remote testing, first start the server:

python -m exif_mcp_server.server \
  --transport streamable-http \
  --host 127.0.0.1 \
  --port 8001

Then connect the Inspector to:

http://127.0.0.1:8001/mcp

Claude Desktop

Claude Desktop's current official direction is different for local and remote servers:

  • local tools are now primarily packaged as desktop extensions (.mcpb)

  • remote MCP servers are added through Settings > Connectors

This repo does not currently ship a Claude Desktop extension bundle, so the most straightforward client setups today are Claude Code, VS Code, Cursor, or MCP Inspector.

MCP Resources

The server publishes two short static resources:

  • exif://privacy-guide

    • practical explanation of EXIF privacy risk

    • what the server removes

    • what the server does not remove

  • exif://supported-formats

    • currently supported image formats

    • overwrite behavior summary

    • stdio-first transport note

MCP Prompts

The server publishes two prompt templates:

  • review-photo-privacy

    • guides a client through inspect_exif, has_gps_exif, and summarize_exif_privacy

  • clean-photos-for-sharing

    • guides a client through safe folder cleanup with batch_strip_exif

Example Tool Calls

Useful local sample paths from this repo:

  • examples/sample_images/plain-no-exif.jpg

  • examples/sample_images/basic-exif.jpg

  • examples/sample_images/gps-exif.jpg

  • examples/sample_images/tiff-exif.tiff

inspect_exif

Input:

{
  "image_path": "/absolute/path/to/photo.jpg"
}

Example output:

{
  "image_path": "/absolute/path/to/photo.jpg",
  "has_exif": true,
  "exif": {
    "Make": "Apple",
    "Model": "iPhone 14",
    "DateTimeOriginal": "2026:04:16 10:30:00"
  },
  "warnings": []
}

inspect_exif_detailed

Input:

{
  "image_path": "/absolute/path/to/photo.jpg"
}

Example output (trimmed):

{
  "image_path": "/absolute/path/to/photo.jpg",
  "has_exif": true,
  "exif": {
    "Artist": "Blue J.",
    "Make": "Canon"
  },
  "warnings": [],
  "tags": [
    {
      "ifd": "0th",
      "tag_id": 315,
      "field_name": "Artist",
      "field_key": "Artist",
      "value": "Blue J."
    }
  ]
}

has_gps_exif

Input:

{
  "image_path": "/absolute/path/to/photo.jpg"
}

find_images_with_gps_exif

Input:

{
  "folder_path": "/absolute/path/to/folder",
  "recursive": false,
  "extensions": null
}

Example output:

{
  "folder_path": "/absolute/path/to/folder",
  "scanned_count": 2,
  "matched_count": 1,
  "failed_count": 0,
  "skipped_count": 1,
  "matches": [
    {
      "image_path": "/absolute/path/to/folder/photo.jpg",
      "gps_fields_present": [
        "GPSLatitude",
        "GPSLatitudeRef",
        "GPSLongitude",
        "GPSLongitudeRef"
      ]
    }
  ],
  "failures": []
}

Example output:

{
  "image_path": "/absolute/path/to/photo.jpg",
  "has_gps": true,
  "gps_fields_present": [
    "GPSLatitude",
    "GPSLatitudeRef",
    "GPSLongitude",
    "GPSLongitudeRef"
  ]
}

find_images_with_exif_fields

Input:

{
  "folder_path": "/absolute/path/to/folder",
  "field_names": ["Artist", "XPAuthor", "Copyright"],
  "match_mode": "any",
  "recursive": false,
  "extensions": null
}

Example output:

{
  "folder_path": "/absolute/path/to/folder",
  "requested_fields": ["Artist", "XPAuthor", "Copyright"],
  "match_mode": "any",
  "scanned_count": 2,
  "matched_count": 1,
  "failed_count": 0,
  "skipped_count": 1,
  "matches": [
    {
      "image_path": "/absolute/path/to/folder/author.jpg",
      "matched_fields": ["Artist"]
    }
  ],
  "failures": []
}

summarize_exif_privacy

Input:

{
  "image_path": "/absolute/path/to/photo.jpg"
}

Example output:

{
  "image_path": "/absolute/path/to/photo.jpg",
  "has_exif": true,
  "privacy_risk": "high",
  "findings": [
    {
      "field": "GPSLatitude",
      "severity": "high",
      "reason": "Location metadata can reveal where the photo was taken."
    }
  ],
  "summary": "This image contains GPS metadata."
}

strip_exif

Input:

{
  "image_path": "/absolute/path/to/photo.jpg",
  "output_path": null,
  "overwrite": false,
  "dry_run": false,
  "include_comparison": false,
  "write_report": false
}

Example output:

{
  "source_path": "/absolute/path/to/photo.jpg",
  "output_path": "/absolute/path/to/photo.cleaned.jpg",
  "removed_exif": true,
  "notes": [
    "Created sibling cleaned file.",
    "Removed EXIF metadata from the written image."
  ]
}

strip_selected_exif_fields

Input:

{
  "image_path": "/absolute/path/to/photo.jpg",
  "field_names": ["Artist", "XPAuthor", "Copyright"],
  "output_path": null,
  "overwrite": false,
  "dry_run": false,
  "include_comparison": false,
  "write_report": false
}

Example output:

{
  "source_path": "/absolute/path/to/photo.jpg",
  "output_path": "/absolute/path/to/photo.cleaned.jpg",
  "removed_fields": ["Artist"],
  "removed_tag_count": 1,
  "notes": [
    "Created sibling cleaned file.",
    "Removed selected EXIF fields from the written image."
  ]
}

batch_strip_exif

Input:

{
  "folder_path": "/absolute/path/to/folder",
  "output_folder": null,
  "recursive": false,
  "overwrite": false,
  "extensions": null,
  "dry_run": false,
  "include_comparison": false,
  "write_report": false
}

batch_strip_selected_exif_fields

Input:

{
  "folder_path": "/absolute/path/to/folder",
  "field_names": ["Artist", "XPAuthor", "Copyright"],
  "output_folder": "/absolute/path/to/cleaned",
  "recursive": false,
  "overwrite": false,
  "extensions": null,
  "dry_run": false,
  "include_comparison": false,
  "write_report": false
}

Example output:

{
  "folder_path": "/absolute/path/to/folder",
  "requested_fields": ["Artist", "XPAuthor", "Copyright"],
  "processed_count": 1,
  "success_count": 1,
  "failed_count": 0,
  "skipped_count": 0,
  "results": [
    {
      "source_path": "/absolute/path/to/folder/author.jpg",
      "output_path": "/absolute/path/to/cleaned/author.cleaned.jpg",
      "status": "success",
      "message": "Selected EXIF fields removed.",
      "removed_fields": ["Artist"],
      "removed_tag_count": 1
    }
  ]
}

batch_strip_gps_exif

Input:

{
  "folder_path": "/absolute/path/to/folder",
  "output_folder": "/absolute/path/to/cleaned",
  "recursive": false,
  "overwrite": false,
  "extensions": null,
  "dry_run": false,
  "include_comparison": false,
  "write_report": false
}

Example output:

{
  "folder_path": "/absolute/path/to/folder",
  "processed_count": 1,
  "success_count": 1,
  "failed_count": 0,
  "skipped_count": 0,
  "results": [
    {
      "source_path": "/absolute/path/to/folder/photo.jpg",
      "output_path": "/absolute/path/to/cleaned/photo.cleaned.jpg",
      "status": "success",
      "message": "GPS EXIF removed.",
      "removed_gps": true
    }
  ]
}

Example output:

{
  "folder_path": "/absolute/path/to/folder",
  "processed_count": 2,
  "success_count": 1,
  "failed_count": 0,
  "skipped_count": 1,
  "results": [
    {
      "source_path": "/absolute/path/to/folder/photo.jpg",
      "output_path": "/absolute/path/to/folder/photo.cleaned.jpg",
      "status": "success",
      "message": "EXIF removed."
    },
    {
      "source_path": "/absolute/path/to/folder/ignore.bmp",
      "status": "skipped",
      "message": "Skipped because the file extension is not selected for batch processing."
    }
  ]
}

Overwrite Safety

The server is safe by default:

  • read-only tools do not modify files

  • strip_exif does not overwrite the source file unless overwrite=true

  • default sibling outputs such as photo.cleaned.jpg or photo.cleaned.png will not overwrite an existing file unless overwrite=true

  • batch_strip_exif continues even if one file fails

  • selective cleanup tools follow the same safe defaults:

    • strip_selected_exif_fields

    • batch_strip_selected_exif_fields

When overwrite=true, the server may rewrite the source image or replace an existing target file.

Optional Cleanup Features

strip_exif, strip_selected_exif_fields, batch_strip_exif, batch_strip_gps_exif, and batch_strip_selected_exif_fields support three optional features:

  • dry_run

    • validate the request and show the predicted output path

    • no image files or report files are written

  • include_comparison

    • include a compact before/after EXIF summary in the result

    • fields:

      • before_has_exif

      • after_has_exif

      • removed_fields

      • remaining_fields

  • write_report

    • write a sidecar JSON report next to each cleaned output image

    • example sidecar path:

      • photo.cleaned.exif-report.json

Example strip_exif dry run:

{
  "image_path": "/absolute/path/to/photo.jpg",
  "dry_run": true,
  "include_comparison": true,
  "write_report": true
}

Example dry-run result:

{
  "source_path": "/absolute/path/to/photo.jpg",
  "output_path": "/absolute/path/to/photo.cleaned.jpg",
  "removed_exif": true,
  "dry_run": true,
  "comparison": {
    "before_has_exif": true,
    "after_has_exif": false,
    "removed_fields": ["DateTimeOriginal", "Make"],
    "remaining_fields": []
  },
  "notes": [
    "Created sibling cleaned file.",
    "Dry run only; no files were written.",
    "Dry run would remove EXIF metadata from the output image.",
    "Dry run skipped writing the sidecar JSON report."
  ]
}

Example sidecar report output:

{
  "source_path": "/absolute/path/to/photo.jpg",
  "output_path": "/absolute/path/to/photo.cleaned.jpg",
  "removed_exif": true,
  "dry_run": false,
  "comparison": {
    "before_has_exif": true,
    "after_has_exif": false,
    "removed_fields": ["DateTimeOriginal", "Make"],
    "remaining_fields": []
  },
  "notes": [
    "Created sibling cleaned file.",
    "Removed EXIF metadata from the written image."
  ]
}

Manual Testing With Sample Images

The repo includes small synthetic images under examples/sample_images/:

  • plain-no-exif.jpg

  • basic-exif.jpg

  • gps-exif.jpg

  • tiff-exif.tiff

Useful manual checks:

  1. Call inspect_exif on basic-exif.jpg and confirm device/timestamp fields are present.

  2. Call has_gps_exif on gps-exif.jpg and confirm GPS fields are detected.

  3. Call summarize_exif_privacy on gps-exif.jpg and confirm the risk is high.

  4. Call strip_exif on gps-exif.jpg and confirm the cleaned output has has_exif: false.

  5. Call find_images_with_gps_exif on a folder and confirm only GPS-bearing files are returned.

  6. Call batch_strip_gps_exif on a folder and confirm GPS data is removed while other EXIF fields remain when possible.

  7. Call batch_strip_exif on examples/sample_images/ and confirm supported files are processed and pre-existing *.cleaned.<ext> outputs are not overwritten unless requested.

  8. Call inspect_exif or strip_exif on tiff-exif.tiff and confirm TIFF EXIF is inspected and cleaned correctly.

  9. Call find_images_with_exif_fields with ["Artist", "XPAuthor", "Copyright"] and confirm only author-bearing files match.

  10. Call batch_strip_selected_exif_fields with an output_folder and confirm selected fields are removed while non-selected EXIF remains.

Tool Error Format

Successful tool responses keep their normal JSON result shapes.

Tool failures are exposed with a stable error string prefix so MCP clients can recognize and parse them predictably:

EXIF_TOOL_ERROR {"code":"file_not_found","message":"...","tool":"inspect_exif"}

Current public error codes include:

  • file_not_found

  • invalid_path

  • invalid_metadata_selection

  • unsupported_image_type

  • exif_read_error

  • exif_write_error

  • unsafe_overwrite

  • exif_error

  • internal_error

Architecture Overview

The project is structured in three layers:

  1. Shared core in src/exif_mcp_server/core/

  2. Thin MCP tool wrappers in src/exif_mcp_server/tools/

  3. Stdio server bootstrap in src/exif_mcp_server/server.py

The MCP layer is intentionally thin. EXIF reading, GPS detection, privacy summary logic, GPS-folder scanning, single-file cleaning, and batch cleaning live in the shared core.

Current Status

The required MVP tools are implemented and the project now goes beyond the original MVP:

  • stdio, streamable-http, and sse transports are available

  • JPG/JPEG/PNG/WebP/TIFF support is implemented and tested

  • optional MCP resources and prompts are implemented

  • GPS-focused folder scan and GPS-only batch cleanup tools are implemented

Still out of scope or future-facing:

  • IPTC or XMP editing

  • cloud storage workflows

  • production auth and deployment hardening for remote transport

License

MIT

Books by the Authors

Available Tools

11 tools
batch_strip_exifC

Remove EXIF metadata from supported images in a folder.

Optional dry-run, comparison, and per-file sidecar-report behavior is available.

ParametersJSON Schema
NameRequiredDescriptionDefault
folder_pathYes
output_folderNo
recursiveNo
overwriteNo
extensionsNo
dry_runNo
include_comparisonNo
write_reportNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
folder_pathYes
processed_countYes
success_countYes
failed_countYes
skipped_countYes
resultsYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It mentions destructive removal and optional dry-run/report but fails to clarify default overwriting behavior, whether files are modified in-place, or error handling. Key details are missing.

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

Conciseness3/5

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

Two sentences are concise but lack structure. The information is front-loaded but could benefit from bullet points or more organized presentation to improve scannability.

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

Completeness2/5

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

Given 8 parameters, sibling tools, and an output schema, the description is incomplete. It doesn't mention return values, supported file types, default behavior, or error handling. For a batch tool with many options, this is insufficient.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must explain parameters. It only hints at folder_path, dry_run, include_comparison, and write_report, but omits output_folder, recursive, overwrite, and extensions. These are critical for correct invocation.

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

Purpose5/5

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

The description clearly states the verb 'Remove' and resource 'EXIF metadata from supported images in a folder'. It implicitly distinguishes from sibling tools like batch_strip_gps_exif and batch_strip_selected_exif_fields by focusing on all EXIF data.

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

Usage Guidelines2/5

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

The description does not provide guidance on when to use this tool versus alternatives like batch_strip_gps_exif or strip_exif for single files. It mentions optional features but lacks explicit usage context or exclusion conditions.

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

batch_strip_gps_exifC

Remove only GPS EXIF metadata from supported images in a folder.

ParametersJSON Schema
NameRequiredDescriptionDefault
folder_pathYes
output_folderNo
recursiveNo
overwriteNo
extensionsNo
dry_runNo
include_comparisonNo
write_reportNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
folder_pathYes
processed_countYes
success_countYes
failed_countYes
skipped_countYes
resultsYes

TDQS

C2.5/5.0
Behavior2/5

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

No annotations are provided, so the description must fully describe behavior. It states it removes only GPS EXIF, implying no other EXIF is affected, but does not disclose whether files are modified in-place, what 'supported images' means, or any security/permission implications. This is insufficient for a tool with no annotations.

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

Conciseness2/5

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

The description is a single sentence, which is concise but overly brief. It fails to provide necessary structure or detail. While concise, it sacrifices completeness; every sentence should earn its place, but this one sentence is insufficient to cover even the basic usage.

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

Completeness1/5

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

Given the complexity (8 parameters, 0% schema coverage, no annotations, many siblings), the description is severely lacking. It does not cover return values, side effects, or parameter usage. The agent would be unable to correctly invoke the tool without additional knowledge.

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

Parameters1/5

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

Schema coverage is 0%, meaning the description provides no information about the 8 parameters. The description does not mention folder_path, output_folder, recursive, or any other parameter. The agent receives no help beyond the raw schema, which is especially problematic for parameters like extensions or dry_run that need context.

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

Purpose5/5

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

The description clearly states the tool removes GPS EXIF metadata from images in a folder. The verb 'remove' and resource 'GPS EXIF metadata' are specific, and the scope 'supported images in a folder' is clear. It distinguishes itself from sibling tools like batch_strip_exif (which removes all EXIF) and batch_strip_selected_exif_fields (which allows field selection).

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

Usage Guidelines2/5

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

The description lacks any guidance on when to use this tool versus its siblings. It does not mention prerequisites, conditions, or exclusions. For a tool with many siblings, this omission leaves the agent without decision criteria.

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

batch_strip_selected_exif_fieldsC

Remove selected EXIF fields from supported images in a folder.

ParametersJSON Schema
NameRequiredDescriptionDefault
folder_pathYes
field_namesYes
output_folderNo
recursiveNo
overwriteNo
extensionsNo
dry_runNo
include_comparisonNo
write_reportNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
folder_pathYes
requested_fieldsYes
processed_countYes
success_countYes
failed_countYes
skipped_countYes
resultsYes

TDQS

C2.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as whether files are modified in-place, handling of output_folder, error behavior, or effects of parameters like overwrite, dry_run, or recursive.

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

Conciseness2/5

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

The description is a single sentence, but for a tool with 9 parameters and an output schema, it is too brief. It does not provide essential information, so it is under-specified rather than concise.

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

Completeness1/5

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

Given the tool's complexity (9 parameters, many optional, no parameter descriptions, no behavioral disclosure), the description is grossly incomplete. It does not explain return values, param dependencies, or how to use the tool effectively.

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

Parameters1/5

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. It gives no information about parameter semantics, formats, or examples for any of the 9 parameters, including required ones like folder_path and field_names.

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

Purpose5/5

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

The description clearly states the action ('Remove'), the resource ('selected EXIF fields'), and the scope ('from supported images in a folder'). It distinguishes from sibling tools that strip all EXIF or GPS EXIF.

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

Usage Guidelines2/5

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 like batch_strip_exif, strip_selected_exif_fields, or when not to use it. Prerequisites or conditions are not mentioned.

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

find_images_with_exif_fieldsC

Find images in one folder containing selected EXIF fields.

ParametersJSON Schema
NameRequiredDescriptionDefault
folder_pathYes
field_namesYes
match_modeNoany
recursiveNo
extensionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
folder_pathYes
requested_fieldsYes
match_modeYes
scanned_countYes
matched_countYes
failed_countYes
skipped_countYes
matchesYes
failuresYes

TDQS

C2.8/5.0
Behavior2/5

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

No annotations exist, and the description does not disclose behavioral traits such as how matches are returned, whether it is read-only, or any side effects. The minimal description fails to compensate for missing annotations.

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 description is a single short sentence, which is concise. However, it sacrifices necessary detail for brevity, making it slightly under-specified for the tool's complexity.

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

Completeness2/5

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

Given the tool has 5 parameters, 2 required, and a likely non-trivial output (though an output schema exists but is unhelpful), the description fails to cover return format, match mode behavior, or filtering nuances. It is incomplete for effective selection and invocation.

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

Parameters1/5

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

The input schema has 5 parameters with no descriptions (0% schema coverage), and the description only vaguely references 'selected EXIF fields' without explaining 'folder_path', 'match_mode', 'recursive', or 'extensions'. The description adds almost no value beyond parameter names.

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

Purpose5/5

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

The description explicitly states the verb 'find', the resource 'images in one folder', and the filter 'containing selected EXIF fields', which clearly distinguishes it from sibling tools like 'find_images_with_gps_exif' or batch operations.

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

Usage Guidelines2/5

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 like 'find_images_with_gps_exif' or 'batch_strip_exif'. There are no explicit context or exclusion statements.

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

find_images_with_gps_exifC

Find images in one folder that contain GPS/location EXIF fields.

ParametersJSON Schema
NameRequiredDescriptionDefault
folder_pathYes
recursiveNo
extensionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
folder_pathYes
scanned_countYes
matched_countYes
failed_countYes
skipped_countYes
matchesYes
failuresYes

TDQS

C2.6/5.0
Behavior2/5

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

No annotations provided; description only states what it does without disclosing side effects, permissions, or error behavior (e.g., non-existent folder). Minimal disclosure for a read-only search.

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

Conciseness3/5

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

Single sentence is concise but lacks detail; it is not verbose, but it under-specifies for a tool with three parameters.

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

Completeness1/5

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

Given no annotations and 0% schema description coverage, the description fails to explain parameters, output, or usage context, leaving significant gaps for an agent.

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

Parameters1/5

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

Schema description coverage is 0%; description does not explain any of the three parameters (folder_path, recursive, extensions) beyond the implicit mention of 'one folder'.

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

Purpose5/5

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

Description clearly states action 'find' and resource 'images with GPS EXIF fields' in 'one folder', distinguishing it from siblings like 'find_images_with_exif_fields' (any EXIF) and 'has_gps_exif' (single image).

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

Usage Guidelines2/5

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; lacks context for selecting between sibling tools like 'find_images_with_exif_fields' or 'has_gps_exif'.

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

has_gps_exifA

Check whether an image contains GPS/location EXIF fields.

This tool is read-only and must not modify the target file.

ParametersJSON Schema
NameRequiredDescriptionDefault
image_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
image_pathYes
has_gpsYes
gps_fields_presentYes

TDQS

A4.1/5.0
Behavior4/5

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

No annotations provided, but the description discloses the tool is read-only and non-destructive. This adequately informs the agent of behavioral traits, though it could add details about return value for non-image files.

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

Conciseness5/5

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

Two sentences, no unnecessary words. The purpose is front-loaded and every sentence serves a clear function.

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?

Given no annotations and an output schema (likely indicating boolean return), the description is minimally complete. It could mention the boolean return value or error handling, but is sufficient for the simple tool.

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

Parameters2/5

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 explain the image_path parameter. The AI must rely solely on the schema, which lacks a description. This fails to add value beyond the schema.

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

Purpose5/5

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

The description clearly states the tool checks for GPS/location EXIF fields, using a specific verb and resource. It distinguishes from siblings like batch_strip_exif and find_images_with_gps_exif.

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

Usage Guidelines4/5

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

The description explicitly states the tool is read-only and must not modify files, guiding appropriate use. However, it does not mention alternatives like strip_exif when removal is needed.

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

inspect_exifA

Read EXIF metadata from a single image path.

This tool is read-only and must not modify the target file.

ParametersJSON Schema
NameRequiredDescriptionDefault
image_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
image_pathYes
has_exifYes
exifYes
warningsYes

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It explicitly states 'read-only and must not modify,' which is transparent about safety. Lacks details on error handling or permissions, but is sufficient for a simple 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.

Conciseness5/5

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

Two concise sentences, front-loaded with the core action, no redundant information.

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?

Given the tool's simplicity, one parameter, and presence of an output schema, the description covers the essential purpose and safety. It could mention return values or paths, but completeness is adequate.

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

Parameters2/5

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

The sole parameter 'image_path' is self-explanatory, but the description adds no extra meaning beyond the schema. With 0% schema coverage, the description fails to compensate by providing context like expected format or constraints.

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

Purpose5/5

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

The description clearly states 'Read EXIF metadata from a single image path,' using a specific verb and resource. It distinguishes from sibling tools like strip_exif or inspect_exif_detailed by focusing on reading without modification.

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?

The description mentions read-only behavior, implying safe usage for metadata inspection. However, it does not explicitly compare with alternatives like inspect_exif_detailed or provide when-not-to-use guidance.

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

inspect_exif_detailedB

Read EXIF metadata with per-tag references for selective cleanup.

ParametersJSON Schema
NameRequiredDescriptionDefault
image_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
image_pathYes
has_exifYes
exifYes
warningsYes
tagsYes

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states read intent; it does not disclose any behavioral traits such as permissions, idempotency, or side effects. The mention of 'selective cleanup' hints at output structure but is insufficient.

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 description is a single concise sentence with front-loaded key action, but lacks structured detail. It is appropriately sized for a simple tool.

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

Completeness3/5

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

Given the tool's simplicity (1 param, output schema exists) and many siblings, the description is minimally complete for a read operation, but fails to explain what 'per-tag references' are or how they aid cleanup.

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

Parameters2/5

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

The single parameter 'image_path' has 0% schema description coverage, and the description adds no additional context about valid formats, constraints, or examples beyond the schema's basic type.

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

Purpose5/5

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

The description clearly states the action ('Read') and the resource ('EXIF metadata'), and adds a distinguishing feature ('with per-tag references for selective cleanup') that differentiates it from the sibling tool 'inspect_exif'.

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

Usage Guidelines2/5

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, lacks prerequisites or exclusions, and does not reference any siblings.

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

strip_exifA

Remove EXIF metadata from a single image.

If output_path is omitted, the shared core will later generate a sibling cleaned file path. Overwrite remains opt-in and defaults to False. Optional dry-run, comparison, and sidecar-report behavior is available.

ParametersJSON Schema
NameRequiredDescriptionDefault
image_pathYes
output_pathNo
overwriteNo
dry_runNo
include_comparisonNo
write_reportNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
source_pathYes
output_pathYes
removed_exifYes
notesYes
dry_runYes
comparisonYes
report_pathYes

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description explains key behaviors: output_path omission generates a sibling path, overwrite defaults to false, and optional dry-run, comparison, and report features. It could clarify if the original file is modified, but overall it is transparent enough.

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

Conciseness5/5

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

The description is two insightful sentences plus a brief third sentence. Every sentence adds value, and the purpose is immediately clear. No wasted words.

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?

Given the tool complexity (6 params, no annotations, but output schema exists), the description covers essential behaviors and optional features. It does not explain error conditions or return values, but the output schema fills that gap. Overall, it is sufficiently complete.

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

Parameters4/5

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

Despite 0% schema description coverage, the description adds meaning for output_path, overwrite, dry_run, include_comparison, and write_report. Only image_path lacks explicit explanation, but it is self-explanatory. This compensates well for the schema gap.

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

Purpose5/5

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

The description clearly states the verb 'Remove' and the resource 'EXIF metadata from a single image'. It distinguishes from sibling tools like batch_strip_exif by specifying 'single image', 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.

Usage Guidelines3/5

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

The description implies single-image use but does not explicitly state when to use this tool vs batch or field-specific alternatives. There is no exclusion guidance or mention of prerequisites.

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

strip_selected_exif_fieldsC

Remove selected EXIF fields from a single image path.

ParametersJSON Schema
NameRequiredDescriptionDefault
image_pathYes
field_namesYes
output_pathNo
overwriteNo
dry_runNo
include_comparisonNo
write_reportNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
source_pathYes
output_pathYes
removed_fieldsYes
removed_tag_countYes
notesYes
dry_runYes
comparisonYes
report_pathYes

TDQS

C2.9/5.0
Behavior2/5

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

Without annotations, the description must disclose side effects and dependencies. It only states 'Remove' without explaining if the operation is destructive (overwrite behavior), if it supports dry runs, or what the output structure is.

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 description is a single, efficient sentence with no wasted words. However, given the complexity of 7 parameters, slightly more detail would improve usability without sacrificing conciseness.

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

Completeness2/5

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

The description fails to cover the tool's behavior for parameters like overwrite, dry_run, or write_report, and does not mention return values despite an existing output schema. Updates to the image or file structure are unclear.

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

Parameters2/5

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

With 0% schema description coverage and no parameter explanations in the description, the agent gains limited insight beyond parameter names. The description does not elaborate on 'field_names' format, nor on flags like overwrite, dry_run, or include_comparison.

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

Purpose5/5

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

The description clearly states the verb ('Remove'), the resource ('selected EXIF fields'), and the scope ('a single image path'), effectively distinguishing it from batch sibling tools.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like batch_strip_selected_exif_fields or inspection tools. The usage context is only implied by the 'single image' qualifier.

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

summarize_exif_privacyC

Summarize privacy-sensitive EXIF fields for a single image path.

ParametersJSON Schema
NameRequiredDescriptionDefault
image_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
image_pathYes
has_exifYes
privacy_riskYes
findingsYes
summaryYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided. Description does not disclose what fields are considered 'privacy-sensitive', output format, or whether it is read-only (likely but unstated). Lacks behavioral detail beyond the name.

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?

Single sentence is efficient, but could be expanded slightly for clarity. No wasted words, but under-informative.

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

Completeness2/5

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

Despite having an output schema, description doesn't explain what the summary contains. Agent cannot determine return value scope. Incomplete for a privacy-related tool.

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

Parameters2/5

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

Only parameter 'image_path' has no schema description. The tool description adds no meaning about path format, validity, or examples. Requires agent to infer from name.

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

Purpose5/5

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

Description clearly states verb 'Summarize', resource 'privacy-sensitive EXIF fields', and scope 'for a single image path'. Distinct from sibling tools like batch operations or detailed inspection.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over alternatives (e.g., inspect_exif, has_gps_exif). No when-not-to-use or context provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 11 tool updatesv0.1.0
    • First observedbatch_strip_exif
    • First observedbatch_strip_gps_exif
    • First observedbatch_strip_selected_exif_fields
    • First observedfind_images_with_exif_fields
    • First observedfind_images_with_gps_exif
    • First observedhas_gps_exif
    • First observedinspect_exif
    • First observedinspect_exif_detailed
    • First observedstrip_exif
    • First observedstrip_selected_exif_fields
    • First observedsummarize_exif_privacy
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool targets a distinct operation (inspect, strip, find) and scope (single file vs batch). Even similar tools like inspect_exif and inspect_exif_detailed are clearly differentiated by level of detail. No overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., strip_exif, batch_strip_gps_exif, find_images_with_exif_fields). No mixing of conventions or vague verbs.

Tool Count5/5

11 tools cover the full range of EXIF operations: inspection, stripping (single/batch, full/partial/GPS), finding files, and privacy summary. The number is appropriate for a focused utility server.

Completeness4/5

The tool set covers core privacy workflows: reading, stripping, and locating EXIF data. Missing write/update/modify operations, but those are not typically needed for EXIF removal. Minor gap but acceptable for the domain.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nextframedev/exif_mcp_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server