Skip to main content
Glama
Sign In
spoofzy

spoofzy

by spoofzy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Spoof images and videos

spoofzy_spoof

Generate unique versions of local images or videos, strip GPS, device and date metadata, and save results to a spoofzy-output folder. Confirms version counts and settings before charging.

Instructions

Make unique versions of local images or videos with the Spoofzy Spoofer. Uploads each file to the user's Spoofzy account, processes it and saves the results as -spoofzy-NN. in a spoofzy-output folder next to the source (or output_dir). Spoofzy Cloud makes 1, 5, 10, 20, 30, 40 or 50 versions per file; the prepaid Spoofer API makes 1 (up to 300 with batch access, otherwise one job per version). This uses the account's allowance: confirm the files, versions and settings with the user first. Returns when done or after wait_seconds; unfinished runs keep going and can be checked with spoofzy_get_run.

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_spoof"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNoOne file path; same as files: [path].
lookNoclassic (default) = standard Spoofzy processing. subtle = lighter changes. stronger = adds small rotation, perspective and framing changes. minimal = keeps existing text and layout (no mirror, rotation or crop), best for captioned reels and images. subtle/stronger need a Cloud membership.
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.
borderNoSpoofzy Cloud Studio only. Adds a coloured border.
mirrorNoMirror the media like Spoofzy's Mirror switch (default false). Flips any visible text; not allowed with minimal.
backendNoWhich Spoofzy API to use: cloud (Spoofzy Cloud key), api (prepaid Spoofer API key) or auto (default: Cloud when configured).
downloadNoSave the results locally (default true). False returns temporary result links instead.
versionsNoVersions per file (default 1). Spoofzy Cloud: 1, 5, 10, 20, 30, 40 or 50.
watermarkNoSpoofzy Cloud Studio only. Default: the account's saved watermark setting.
output_dirNoFolder for the results (created if needed). Default: a spoofzy-output folder next to each source file, or the configured SPOOFZY_OUTPUT_DIR.
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.
export_sizeNoOutput size (default original). Other sizes need Cloud Studio or prepaid batch access.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, it discloses that files are uploaded to the user's Spoofzy account (an external side effect consistent with openWorldHint), that the call consumes the account's prepaid allowance, and that results are written to disk next to the source. It also supplies an idempotency workaround (request_id returns the same runs instead of charging again) that meaningfully compensates for idempotentHint=false.

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?

Four sentences, front-loaded with purpose then mechanics, with no filler. It is dense with backend-specific detail, and a reader must hold cloud-vs-api exceptions across two sentences, but every clause carries operational 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?

For a 13-parameter, nested-object, no-output-schema tool this covers the essentials: where files go, how they are named, what happens when the wait expires, and how to follow up. The one gap is that it never says what the return payload contains (run identifiers, links when download=false), leaving the agent to infer the shape of results.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot express: Cloud allows only 1/5/10/20/30/40/50 versions while the prepaid API allows 1 (or up to 300 with batch access), and backend=auto defaults to Cloud when configured. It also names the env-var source for the wait_seconds default, which the schema does not.

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?

"Make unique versions of local images or videos with the Spoofzy Spoofer" gives a specific verb and resource, then specifies the full pipeline (upload to the user's account, process, save as <name>-spoofzy-NN.<ext> in a spoofzy-output folder). The output naming and location convention alone lets an agent distinguish this from spoofzy_run_workflow or spoofzy_download without opening a schema.

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 sets clear preconditions ("confirm the files, versions and settings with the user first"), explains the async hand-off ("unfinished runs ... can be checked with spoofzy_get_run"), and scopes request_id to retries of uncertain outcomes. It does not say when to prefer spoofzy_run_workflow instead, so the alternative-selection guidance is strong but not exhaustive.

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