Skip to main content
Glama
Sign In
spoofzy

spoofzy

by spoofzy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Strip photo and video metadata

spoofzy_clean_metadata

Remove hidden GPS, device, and capture-date metadata from local photos and videos, saving cleaned copies while leaving originals unchanged.

Instructions

Remove hidden metadata (GPS location, device and camera details, capture dates) from local photos or videos with Spoofzy's Metadata Cleaner (needs a Spoofzy Cloud key). Saves cleaned copies as -clean-NN. in a spoofzy-output folder next to each source (or output_dir); originals are never modified. Uses the account's allowance: confirm first.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "spoofzy_clean_metadata"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNoOne file path; same as files: [path].
filesNoAbsolute paths of local images/videos, or folders (every supported file directly inside). Up to 20 files per call. Supported: JPG, PNG, WebP, HEIC, GIF, MP4, MOV, M4V and WebM.
downloadNoSave the results locally (default true). False returns temporary result links instead.
output_dirNoFolder for the results (created if needed). Default: a spoofzy-output folder next to each source file, or the configured SPOOFZY_OUTPUT_DIR.
remove_gpsNoRemove location data (default true).
request_idNoOnly to retry a call whose outcome was uncertain: pass the request_id it returned and Spoofzy returns the same runs instead of charging again. Leave empty for new runs.
wait_secondsNoSeconds to wait for processing before returning (default from SPOOFZY_WAIT_SECONDS, normally 50). Unfinished runs keep processing and are saved when ready while this server runs; check them with spoofzy_get_run.
remove_deviceNoRemove device/camera details (default true).
remove_datetimeNoRemove capture dates (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing that originals are never modified, that cleaned copies land in a spoofzy-output folder with a <name>-clean-NN.<ext> pattern, and that the call consumes account allowance. This is meaningful new context alongside readOnlyHint=false and destructiveHint=false, with no contradiction between them.

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?

Three tight sentences with the capability front-loaded, followed by output behavior and then the billing caveat. Every clause carries information an agent needs and none repeats structured data verbatim.

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?

For a nine-parameter, non-destructive write tool with no output schema, the description covers what is produced, where, and under what cost constraint. Remaining operational details (async waiting, run retrieval, retry via request_id) are already carried by the schema parameter descriptions, so only minor gaps remain.

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 coverage is 100%, so all nine parameters (file/files, download, output_dir, the three remove_* flags, request_id, wait_seconds) are already documented in the schema. The description reinforces the output naming and directory default but adds no semantics the schema lacks, so the baseline of 3 applies.

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?

States a specific verb ('Remove') plus the exact resource and sub-fields ('hidden metadata (GPS location, device and camera details, capture dates)') on local photos or videos. This is clearly distinguishable from siblings such as spoofzy_spoof or spoofzy_run_workflow, which are workflow/identity tools rather than a metadata scrubber.

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?

Gives prerequisites ('needs a Spoofzy Cloud key') and an explicit procedural instruction ('Uses the account's allowance: confirm first'), so an agent knows to confirm before spending credits. It does not name a sibling alternative or state exclusions, which keeps it short of a 5.

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