Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@snapWONDERS MCP hide my notes.txt inside vacation.jpg with the password hunter2"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
snapWONDERS — Expose what's hidden. Hide what's yours.
A local MCP server that lets an AI assistant work on files on your own machine — hide a file inside a photo, reveal hidden content, run forensic analysis, or convert between formats.
Claude Desktop ──stdio──▶ snapwonders-mcp ──HTTPS──▶ snapwonders.com/api
(your machine) (your machine)snapWONDERS already has a remote MCP server at https://snapwonders.com/mcp, and for
orchestration it works well. But it runs on our servers — so it cannot see your files, and MCP
tool calls carry JSON rather than bytes. An assistant with a photo on your desktop could create a
session and then have nowhere to put the file.
This server runs where your files are. You give it a path, it reads the file locally and uploads it over HTTPS alongside the conversation. That is the whole difference, and it is what makes snapWONDERS usable from Claude Desktop, which has no terminal for an assistant to fall back on.
Results come back the same way: a hide, reveal or convert writes the output to your disk and tells the assistant where it landed — not an asset id you would need a separate HTTP client to redeem.
Related MCP server: UFC-MCP
You need an API key from https://snapwonders.com/profile/api-keys (free account, and the address must be verified — an unverified account's keys are always rejected).
Nothing to install ahead of time if your client can run uvx:
uvx snapwonders-mcpOr install it properly:
pip install snapwonders-mcp%APPDATA%\Claude\claude_desktop_config.json on Windows,
~/Library/Application Support/Claude/claude_desktop_config.json on macOS:
{
"mcpServers": {
"snapwonders": {
"command": "uvx",
"args": ["snapwonders-mcp"],
"env": { "SNAPWONDERS_API_KEY": "sw_your_key_here" }
}
}
}claude mcp add snapwonders --env SNAPWONDERS_API_KEY=sw_your_key_here -- uvx snapwonders-mcp~/.cursor/mcp.json (global) or .cursor/mcp.json (project):
{
"mcpServers": {
"snapwonders": {
"command": "uvx",
"args": ["snapwonders-mcp"],
"env": { "SNAPWONDERS_API_KEY": "sw_your_key_here" }
}
}
}The key is read from the environment, never taken as a tool argument — so it does not pass through the model's context, where it would end up in transcripts and logs.
Passwords are different, and you should know it. hide_file and reveal_file take the
passphrase as a tool argument, because only the user can supply it and it changes per call.
That means it does pass through the model's context and may appear in client logs and
transcripts. There is no way around that in an assistant-driven flow — but the care taken with
the API key does not extend to the passphrase, so treat anything you hide through an assistant
accordingly.
This server can upload any file you can read. That is the point of it — an assistant asks for a path and the file is sent to snapWONDERS for processing. It also means a request like "analyse ~/.ssh/id_rsa" would do exactly that, and an assistant following instructions from a web page or document it has read could try to use it that way. Your MCP client's tool-approval prompt is the real gate: read the path in the tool call before approving it.
Tool | What it does |
| Forensic analysis of a local image or video — A–F grade, metadata exposure, manipulation evidence, hidden content. Optional face detection and OCR. |
| Conceal a file inside a cover image or video, and save the result to disk. |
| Extract content hidden in an image or video, and save it to disk. |
| Convert an image or video to another format, and save the output to disk. |
Four tools, each a whole task. The REST API underneath is a session → upload → job → poll → results sequence; exposed one call per step, a model has to carry five-step state and will sometimes get it wrong. The orchestration lives here in Python instead, where it is deterministic.
Passwords for
hide_fileare not recoverable. They are never stored, and there is no reset. Be sure the user knows the passphrase before hiding something with it.
https://snapwonders.com/mcp needs no install and is right when the files are already
somewhere the server can reach, or when you only want session and job orchestration. Use this
local server when the files are on the user's machine — which, for a desktop assistant, is
almost always.
Whichever fits, and you never choose: the Python SDK sends anything under the server-reported cap (currently 95 MB) as a single direct upload, and falls back to the resumable TUS protocol above it.
This project started with my son, Huey.
Huey lost his eyesight and was legally blind from the age of four. Years ago, in the car, while we were working on Hueyify together, he insisted the idea could be applied to digital media: stories embedded inside a photo, so that people with vision impairments could get the personal context, the memory and the feeling behind it. Hidden from everyone else. Only for the person it was meant for.
He was excited at the thought of it. I'll admit the technical difficulty put me off, and I was vocal about it. The look of disappointment kept returning to me, because to Huey it all made sense. We lost Huey at sixteen. I could never let go of that conversation.
snapWONDERS came first, to understand what digital media actually contains and who can see it. Vaultify came after, and it is the closest thing I've built to what Huey described. As of September 2026, snapWONDERS and Vaultify have processed more than six million media jobs.
The full story is at https://vaultify.snapwonders.com/our-story
May peace be with you, Kenneth Springer
MIT — see LICENSE. The licence covers this server only; the snapWONDERS API it calls is proprietary.
Run forensic analysis on a local image or video and return the per-file verdicts.
Reports the A–F grade, what the metadata reveals (GPS, device fingerprint, encoder signatures), manipulation evidence, and any hidden content detected.
A null verdict means no answer, not a negative one. Fields such as
steganography_suspected come back null when that check produced no result — because it
was skipped, or could not run on this file. Do not report a file as clean, unmodified or free
of hidden content on the strength of a null; say the check did not return a verdict.
Args:
file_path: Path to a file on this machine. ~ and relative paths are fine.
face_detection: Locate faces and return a count. On by default, matching the API.
text_detection: Run OCR and return detected text. On by default, matching the API.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| face_detection | No | ||
| text_detection | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers notable value: it discloses what the response contains and gives a strong interpretation caveat that null verdicts mean 'no answer, not a negative' and must not be reported as clean. It omits whether the file is uploaded off-machine, whether the operation is read-only/non-destructive to the file, and any size/format/latency limits, which are relevant gaps for a forensic tool with zero annotation coverage.
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?
Front-loaded with purpose, then return content, then the critical null-semantics warning, then args — a sensible order with no filler sentences. The null explanation is longer than strictly necessary and the Args block partially restates the schema, but both earn their place given the 0% schema coverage and the risk of misreading nulls.
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?
An output schema exists, so the return format needn't be fully spelled out, and the description still covers the fields that matter for correct interpretation. Remaining gaps are the operation's read-only character, whether the file leaves the local machine, and supported formats/size envelopes — useful but not fatal for calling it correctly.
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 0%, yet the description adds real meaning for all three parameters: file_path accepts local paths with ~ and relative forms, face_detection locates faces and returns a count, and text_detection runs OCR and returns detected text, with both defaulting on to match the API. That fully compensates for the empty schema descriptions.
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 (run forensic analysis) and resource (local image or video) plus the output shape (per-file verdicts, A–F grade, metadata, manipulation evidence, hidden content). This is clearly distinguishable from the sibling hide_file/reveal_file/convert_file operations.
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?
Usage is implied by the verb — you use this when you want a forensic verdict on a file — but there is no explicit when-to-use statement, no when-not, and no reference to the sibling tools or to how this relates to convert_file/reveal_file workflows. Nothing is misleading, but the routing guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a local image or video to another format, and save the output to disk.
Args:
file_path: The file to convert.
output_format: Target format. Images: jpeg, png, webp, avif, heic,
jxl. Videos: mp4h264, mp4h265, webm, mkv, mov.
output_dir: Where to write the converted file. Defaults to alongside the input.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| output_dir | No | ||
| output_format | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the side effect ('save the output to disk') and the default write location, but says nothing about overwriting existing files, whether the source is modified, permission requirements, or what happens on an unsupported source/target combination.
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?
The purpose sentence is front-loaded and the Args block is scannable per-parameter. Slightly verbose with blank lines between entries, but no sentence is wasted.
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?
An output schema exists, so return values need not be documented, and the description covers purpose, all parameters, and the write destination. Remaining gaps are error/edge-case behavior (unsupported conversions, overwrite handling) rather than anything blocking a correct invocation.
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 0%, so the description must compensate, and it largely does: it explains all three parameters and enumerates the valid output_format values per media type, information absent from the schema (no enum constraints defined). It stops short of specifying format syntax (extension vs. mime), case sensitivity, or whether the format can be inferred from the file.
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 (convert), resource (local image or video), and outcome (save the output to disk) with an explicit scope qualifier ('local'). The siblings (analyse_file, hide_file, reveal_file) are unrelated operations, so no disambiguation text is needed for the agent to pick this tool correctly.
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?
Usage is implied by 'local image or video' plus the format lists, which tell the agent what inputs are in scope. However, there is no explicit when-to-use statement, no exclusion for cross-type conversions (e.g. image → mp4), and no mention of failure modes or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hide a file inside a cover image or video, and save the result to disk.
The output looks like an ordinary photo or video. Recovering the hidden file needs this exact password — it is not stored anywhere and cannot be reset, so make sure the user knows what it is before running this.
Args: secret_path: The file to conceal. cover_path: The image or video that will carry it. password: Passphrase required to reveal it later. output_dir: Where to write the result. Defaults to alongside the cover file.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | ||
| cover_path | Yes | ||
| output_dir | No | ||
| secret_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: the output masquerades as an ordinary photo/video, the password is not stored anywhere and cannot be reset, and the result is written to disk. It omits limits worth knowing (format/size constraints, whether output_dir must pre-exist, overwrite behavior), so it is strong but not complete.
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?
The critical constraint (password is unrecoverable) is front-loaded in the second paragraph, and the args list is tight and one line per parameter. Slightly more prose than strictly needed, but nothing is wasted.
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?
An output schema exists, so return values need not be described, and the description supplies the safety-critical context an agent needs (password irrecoverability, output location). The remaining gap is edge-case behavior around the files involved, which is minor for this tool's complexity.
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 0%, so the description must compensate, and it does: every one of the four parameters is explained semantically (secret_path = file to conceal, cover_path = carrier medium, password = reveal passphrase, output_dir = destination with a stated default). This exceeds what the bare schema titles provide.
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: 'Hide a file inside a cover image or video, and save the result to disk.' The inverse operation (reveal_file) is implied by 'Recovering the hidden file needs this exact password,' which gives enough contrast to place it among its siblings, though no sibling is named explicitly.
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?
Gives clear context for when to use it (concealing a file inside a carrier medium) plus an important precondition: confirm the password with the user before running, since it cannot be reset. No explicit alternatives are offered, but the reveal/recover framing implicitly scopes the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract content hidden inside an image or video, and save it to disk.
Args: stego_path: The file believed to contain hidden content. password: The passphrase it was hidden with. output_dir: Where to write what is recovered. Defaults to alongside the input.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | ||
| output_dir | No | ||
| stego_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key side effect: content is written to disk, with a default location 'alongside the input.' However, it omits failure behavior (wrong password), whether existing files are overwritten, and any permission considerations for a write operation.
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?
The core action is front-loaded in one sentence, followed by a compact Args block that earns its place by supplying the semantics the empty schema lacks. No filler sentences.
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?
An output schema exists, so return values need no explanation, and all three parameters are documented. The remaining shortfall is behavioral: as an unannotated write tool, error/overwrite behavior is unstated, though the disk-write side effect itself is surfaced.
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 0%, so the description must compensate, and it does: all three parameters are given semantics beyond their names — stego_path as the suspected carrier file, password as the hiding passphrase, and output_dir as the write target defaulting to alongside the input. Minor gap: no format guidance for password or path strings.
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: 'Extract content hidden inside an image or video, and save it to disk.' This clearly contrasts with the inverse sibling hide_file, but it never explicitly distinguishes itself from analyse_file, which is the tool an agent is most likely to confuse it with (detecting vs. recovering content). Clear purpose, no explicit sibling routing.
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?
Usage is only implied by the phrase 'the file believed to contain hidden content,' which hints that you should already suspect hidden content exists. There is no explicit statement of when to use this over analyse_file (detection) or what prerequisites apply, so the agent must infer the routing.
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.
v0.1.2analyse_fileconvert_filehide_filereveal_fileScored across 4 tools
Each tool has a clearly distinct action on a file: analyse (forensic report), hide (embed), reveal (extract), convert (transcode). analyse_file and reveal_file both touch hidden content, but analyse only reports verdicts while reveal extracts with a password, and the descriptions make that distinction explicit.
All four names follow the same verb_noun snake_case pattern (analyse_file, hide_file, reveal_file, convert_file). The verb is always the operation and the noun is consistently 'file', with no mixed conventions.
Four tools sits comfortably in the 3-15 sweet spot and each covers a distinct, non-overlapping operation in the media-forensics workflow. There are no filler or redundant tools, and the scope is tightly matched to the server's stated purpose.
The core lifecycle is covered: forensic analysis, steganographic embedding, extraction, and format conversion. Minor gaps remain—no batch/multi-file processing, no standalone metadata export, and no verification-only path that avoids writing an output file—but these are workaround-able.
Inspection, steganography and forensics API for files and images. Bitcoin pay-per-use.
Transform video, audio and images, and generate media from prompts. FFmpeg, captions, models.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
