This server lets you vet documents before they reach an agent or get released: it checks for tampering/fraud signals, prompt-injection text, redaction failures, and document identity.
Inspect documents for tampering/fraud (inspect_document): detects revisions after original save, conflicting metadata, editor fingerprints, signature gaps, hidden text, macros, AI-generator traces, and text aimed at language models rather than readers; returns risk signals with evidence, not verdicts.
Triage documents cheaply (triage_document): pre-flight scan of structure/metadata/signatures to estimate ingest risk and cost (bytes read, expanded, expansion ratio) without the expensive per-page walk.
Check redactions really removed content (check_redaction): catches black-box-only redactions and unapplied redaction marks in PDFs.
Compare documents (compare_documents): tells you if a candidate is byte-identical, has the original as a byte prefix, or differs structurally.
Accept a wide range of files: PDF, Word/Excel/PowerPoint (including macro-enabled), and JPEG/PNG/WebP/HEIC/AVIF images.
Read from local paths or URLs: tools accept either files on your machine or http/https URLs fetched locally, with SSRF protections, redirect re-checks, timeouts, and size caps.
No content enters the model context: recovered payloads are elided, and files are sent as bytes without base64 blobs in tool calls.
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., "@tamperlens-mcp Check this PDF for tampering and hidden text before my agent reads it."
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.
MCP server for Tamperlens — ask whether a document was edited, whether its redactions held, and whether it is safe for a model to read, before it reaches your agent's context.
// Claude Desktop / Claude Code — claude_desktop_config.json or .mcp.json
{
"mcpServers": {
"tamperlens": {
"command": "npx",
"args": ["-y", "tamperlens-mcp"],
"env": { "TAMPERLENS_API_KEY": "tl_..." }
}
}
}No key is required to try it — without one you get the anonymous allowance of 10 documents an hour. A free key at tamperlens.com/account raises that to 50 a month with no card.
Tool | Answers |
| Was this edited after it was written? Revisions appended after the original save, metadata that disagrees with itself, editor fingerprints, signature coverage and integrity, hidden text, macros, AI-generator traces in images — and whether the file carries text addressed to a language model rather than to a reader. |
| Is this worth ingesting, and what does it cost to open? The cheap pre-flight: structure, metadata, signatures and presence flags only — no per-page content walk — at a fraction of the I/O. Returns the risk band, the measured cost (bytes read, bytes expanded, expansion ratio) and a |
| Did the redaction actually remove anything? Covering text with a black box hides it from a person and removes nothing from the file. |
| Is this the same file as the original I already hold, unchanged? |
Accepts PDF; Word, Excel and PowerPoint (.docx, .xlsx, .pptx and the
macro-enabled twins); and JPEG, PNG, WebP, HEIC/HEIF and AVIF.
inspect_document, check_redaction and compare_documents (as
originalUrl/candidateUrl) take either a local path or an http/https
url — not both. A url is fetched by this server, on your own machine, over
your own network, and only the bytes are sent on to Tamperlens. That is why the
option lives here and not on the REST API: a server-side fetch of a
caller-supplied URL is an SSRF risk on the API host, whereas fetching from your
machine reaches only what you can already reach. It is still guarded: http/https
only (re-checked at every redirect), a redirect cap, a 30s timeout
(TAMPERLENS_FETCH_TIMEOUT_MS to tune), and the same 10 MB cap, enforced on the
bytes received rather than a Content-Length that can lie.
It also checks the destination IP, not just the scheme: a url that points
at — or redirects to, or resolves by DNS to — a loopback, link-local/metadata
(169.254.169.254), private or otherwise non-routable address is refused, and
the address it connects to is pinned to the one it validated, so DNS rebinding
cannot slip an internal address past the check. The check re-runs at every
redirect hop. If you genuinely need to fetch from an internal host, allow-list
specific addresses with TAMPERLENS_FETCH_ALLOW_IPS (comma-separated; empty by
default, and the default reaches nothing internal).
The
pathargument reads any local file and sends its bytes to the API.inspect_document,triage_document,check_redactionandcompare_documentsread whatever local path they are given — there is no directory sandbox by default and no extension filter, because reading a document off disk is the whole job and an intake path is not knowable in advance. SetTAMPERLENS_ALLOWED_DIRS(env table below) to confine reads to an intake directory; a symlink pointing out of a root is resolved and refused. The bytes of that file are then transmitted to the configured Tamperlens deployment. A model an attacker is steering could therefore name a private file (~/.ssh/id_rsa,~/.aws/credentials) and cause its bytes to leave the machine. Run this server only with agents and inputs you trust, the same rule you would apply to any tool that can read the local filesystem. For a hard boundary, front the intake with a directory you control and pass only paths inside it.
Related MCP server: @actalumen/mcp-server
A document is read by two audiences and only one of them sees the page. An extraction pipeline reads the title, the keywords, the XMP packet, the comments, the names of attachments — fields that exist to be read by software. Text placed there can be written to be obeyed rather than read.
inspect_document reports that before your agent ingests the file, and the
recovered payload is elided unconditionally in this server. That is not a
convenience: the most likely next reader of a Tamperlens report is the same
model that was about to read the document, so an MCP server that echoed the
attacker's sentence back into the context would be completing the attack it
just detected. You get the field, the location and the cue categories. You do
not get the sentence.
No local analysis. Every tool is a thin wrapper over the Tamperlens REST API on a running deployment. There is no second engine here to drift from the first.
No verdicts. Tamperlens reports risk signals with the evidence behind them, never "this document is fraudulent". Combine them with your own decision logic.
The document never enters the model's context. Tools take a path on the caller's filesystem (or a URL fetched here) and read the bytes on this side. Base64 in a tool call would put megabytes of document into the context window to reach a service that needs the bytes, not the model.
Nothing is stored. Files are parsed in memory by the API and discarded with the response.
Variable | Default | Meaning |
| none | Optional. Without it the anonymous allowance applies (10 documents/hour). |
|
| Point at your own deployment. |
|
| Total budget for a |
| none | Comma-separated exact IPs a |
| none | Colon- or comma-separated absolute directories to confine local file reads to. Unset means any absolute path the process can read. Set it to an intake directory so a |
Field guide to every signal · Is this file safe for your model to read? · API reference · Security and privacy posture
MIT licensed. Issues and source: github.com/haruodev/tamperlens-mcp.
Check whether a PDF's redactions actually removed anything. Covering text with a black box hides it from a reader and removes nothing from the file, so the words stay extractable. This reads paint order to catch a plain drawn rectangle — which carries no redaction annotation at all and is the failure behind most published redaction leaks — and separately catches redaction marks that were never applied. Use this before a document is filed or released.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | http:/https: URL to fetch the PDF from. The fetch runs LOCALLY, over this machine's own network (not from the Tamperlens server), and only the bytes are sent on. Only http/https; redirects re-checked; max 10 MB, enforced on the bytes received. Give this OR path, not both. | |
| path | No | Absolute path to the PDF on this machine. Max 10 MB. Give this OR url, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses how the check works (reads paint order), what it catches (plain rectangles and unapplied redaction marks), and a key security-relevant limitation of visual redaction. It could go further by describing expected output or side effects, but as a read-oriented check, the behavior is substantially transparent.
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 description is only a few sentences but packs in purpose, diagnostic mechanism, a common failure scenario, and a usage reminder. Every sentence contributes, and the primary purpose is front-loaded.
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?
The description plus the comprehensive input schema give an agent both selection and invocation information: what it does, what failure it detects, who should call it, and what parameters are needed. It lacks an explicit statement of the return value, and it does not disambiguate how this complements inspect_document or triage_document, but this is otherwise complete enough for effective use.
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 100%, with detailed descriptions for both url and path already included. The tool description adds no additional parameter-level meaning beyond clarifying that a PDF is the subject of the check. Baseline 3 applies because the schema does the heavy lifting.
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?
The description states a specific verb and resource: "Check whether a PDF's redactions actually removed anything." It goes further by explaining the two distinct failure modes it catches (plain drawn rectangles and never-applied redaction marks), which clearly distinguishes it from the more generic sibling tools like inspect_document.
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?
The description gives clear usage context: "Use this before a document is filed or released." It also explains why that timing matters by describing the common visual-redaction failure. However, it does not explicitly contrast this with sibling tools or state when to choose one of the other document tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a candidate document against the original you already hold, and answer the question a single-file check cannot: is this the same file, unchanged? Reports byte identity (the only proof), revision ancestry when the candidate contains the original as a byte prefix, or a field-by-field structural diff when both were rewritten whole. Renders nothing and compares no pixels.
| Name | Required | Description | Default |
|---|---|---|---|
| originalUrl | No | http:/https: URL to fetch the trusted document from. Fetched LOCALLY over this machine's network (not from the Tamperlens server); http/https only, redirects re-checked, max 10 MB on the bytes received. Give this OR originalPath, not both. | |
| candidateUrl | No | http:/https: URL to fetch the document being checked from. Fetched LOCALLY over this machine's network (not from the Tamperlens server); http/https only, redirects re-checked, max 10 MB on the bytes received. Give this OR candidatePath, not both. | |
| originalPath | No | Absolute path to the document you trust. Give this OR originalUrl, not both. | |
| candidatePath | No | Absolute path to the document being checked. Give this OR candidateUrl, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral disclosure. It does well by specifying three concrete result modes: byte identity, revision ancestry via byte-prefix matching, and field-by-field structural diff. It also adds negatives ('Renders nothing and compares no pixels'), which prevents common misconceptions. It does not mention effects, permissions, or edge cases, but this is a read-only comparison tool and the description largely covers its behavior.
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 description is two tight sentences with no filler. The first sentence frames the purpose and value question, and the second enumerates outcomes succinctly. Every clause earns its place.
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?
Given there is no output schema, the description compensates by naming the three possible result categories (byte identity, revision ancestry, structural diff). The input schema fully covers parameters. It lacks only concrete boolean/response shape details, but an agent can reasonably infer what to expect and when to invoke the tool.
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 100%, so the schema already documents all four parameters well. The description adds modest context by framing one document as trusted ('the original you already hold') and the other as candidate, but it does not need to elaborate on URL/PATH mechanics because the schema already covers them. This matches the baseline for full schema coverage.
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?
The description names a specific verb ('Compare'), a clear resource (candidate document against the original you hold), and the central question ('is this the same file, unchanged?'). It is easily distinguished from sibling tools that inspect, triage, or check redaction.
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?
The description clearly positions this tool as the multi-file comparison tool, saying it answers what 'a single-file check cannot.' It implies when to use it: when an original already exists and an unchanged/revision/diff verdict is needed. It does not explicitly name sibling alternatives or give exclusion conditions, so it stops 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.
Inspect a document or image for fraud and tamper signals: revisions appended after the original save, metadata that disagrees with itself, editor fingerprints, signature coverage gaps, text still readable under a redaction box, unaccepted tracked changes whose deleted text is still recoverable, hidden text, hidden spreadsheet sheets, macros, and AI-generator or editor traces in images. Returns risk signals with the raw evidence behind each one — never a verdict on authenticity. Accepts PDF; Word, Excel and PowerPoint documents (.docx, .xlsx, .pptx and macro-enabled twins); and JPEG, PNG, WebP, HEIC/HEIF and AVIF images.
ALSO ANSWERS: is this file safe for a model to read? Document properties, XMP, annotations, attachment names, docProps, comments and hidden Word runs are checked for text written to be read by a language model rather than by a person — the prompt-injection carriers an extraction pipeline surfaces and a human reader never sees. Call this BEFORE the document reaches your own context. The recovered text itself is never returned through this tool: you get the cue categories, the counts and which kind of field carried it, because reading the payload is the attack.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | http:/https: URL to fetch the document from. The fetch runs LOCALLY, over this machine's own network (not from the Tamperlens server), and only the bytes are sent on. Only http/https is accepted; redirects are followed but re-checked; max 10 MB, enforced on the bytes received. Give this OR path, not both. | |
| path | No | Absolute path to the document on this machine — PDF, Office document or image. Max 10 MB. Give this OR url, not both. | |
| issuer | No | Optional issuer slug (e.g. 'chase') to additionally compare the document against a structural baseline of genuine documents from that institution. PDFs only — ignored for Office documents and images. | |
| policy | No | Optional. Your own risk thresholds and signal rules; the response gains a verdict of accept/review/reject computed from them. Nothing about the report changes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does it well: it states the tool never reports an authenticity verdict, never returns recovered text because reading the payload is the attack, and flags prompt-injection carriers. It does not disclose much about side effects or resource constraints beyond what is already in the parameter schema.
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 description is compact but dense; it front-loads the core purpose and uses the second paragraph for the prompt-injection 'ALSO ANSWERS' handling. The first sentence is long but each special is relevant, and nothing is flatly 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?
Despite the absence of an output schema, the description discloses what is returned (risk signals plus raw evidence), what is explicitly NOT returned (recovered text and verdicts), the accepted file formats, and the key usage warning about lodel context. For an AI agent deciding whether and when to invoke this tool, the description is effectively complete.
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?
The input schema already documents all four parameters and covers 100% of the parameter semantics, including the url/path exclusivity, 10 MB limit, issuer behavior, and policy thresholds. The description adds only high-level format context, not additional parameter meaning, so the baseline score of 3 is appropriate.
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?
The description has a specific verb and resource ('Inspect a document or image') followed by a concrete list of fraud and tamper signals, so an agent can understand exactly what the tool investigates. It does not explicitly distinguish itself from the siblings (triage_document, check_redaction, compare_documents), so it falls just short of full sibling differentiation.
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?
The description gives a clear directive: call this BEFORE the document reaches the model's context, especially for prompt-injection checking. It does not explicitly state when to use the sibling tools instead, but the 'ALSO ANSWERS' section provides a strong practical entry condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CHEAP PRE-FLIGHT for document intake: is this file worth ingesting, and what does it cost to open? Reads structure, metadata, signatures and presence flags (revisions appended after the original, editor fingerprints, macros, JavaScript, embedded files, signature coverage) WITHOUT the expensive per-page content walk — a fraction of the I/O of inspect_document. Returns the risk band, the medium-or-high signals it CAN see, and the measured cost: bytes read, bytes expanded (decompressed) and the expansion ratio, so an agent can reject a decompression-heavy or high-risk file before committing to a full parse.
NOT A CLEAN BILL OF HEALTH. A quiet triage means only that the cheap structural tells were absent. Hidden text, redaction failure, altered arithmetic, glyph tampering, embedded-image anomalies and broken certifications are NOT checked in this mode — they need the page-content walk inspect_document runs. Use triage to ROUTE (reject now, or escalate to inspect_document), never as the verdict. PDFs get the cheap scope; Office documents and images have no separate expensive walk, so they return their full report.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the document on this machine — PDF, Office document or image. Max 10 MB. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden and handles it well. It discloses exactly what is read, what is returned, and what is NOT checked (hidden text, redaction failures, altered arithmetic, etc.). It also warns that a quiet triage is not a clean bill of health and explains the measured cost output.
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 description is longer than average, but every sentence earns its place: the core purpose is front-loaded, and the caveats and scope differences are critical to correct agent behavior. It could be slightly tightened, but the length is justified by the complexity and by the need to prevent the tool from being treated as a full inspection.
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?
The description covers the tool's purpose, alternatives, inputs, outputs, limitations, and non-verdict framing. There is no output schema and no annotations, so the description must carry all the information an agent needs to decide whether to invoke this tool and how to interpret the result. It qualifies as common.
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?
The single parameter 'path' is fully covered by the schema, which already states it is an absolute path, the acceptable file formats, and the 10 MB limit. The description adds incidental context about PDFs versus Office documents but does not add param-specific semantics beyond the schema. The baseline of 3 for full schema coverage applies.
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?
The description opens with a specific action: a cheap pre-flight for document intake. It names the resource (document) and its core outcome (is it worth ingesting, what does opening cost), and differentiates itself from the sibling inspect_document by saying it avoids the expensive per-page walk. This is a precise, non-circular statement that an agent can use to decide between the tools.
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?
The description says exactly when to use this tool: to route or reject before a full parse, never as a verdict. It explicitly names inspect_document as the alternative for page-content analysis, and notes that PDFs get a cheap scope while Office documents and images return full reports. That is concrete routing guidance.
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.
v1.35.0check_redaction3 fields changedInput schema / properties / path / descriptionPrevious value: -"Absolute path to the PDF on this machine. Max 10 MB."New value: +"Absolute path to the PDF on this machine. Max 10 MB. Give this OR url, not both."Input schema / properties / urlAdded value: +{
+ "description": "http:/https: URL to fetch the PDF from. The fetch runs LOCALLY, over this machine's own network (not from the Tamperlens server), and only the bytes are sent on. Only http/https; redirects re-checked; max 10 MB, enforced on the bytes received. Give this OR path, not both.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "path"
-]compare_documents5 fields changedInput schema / properties / candidatePath / descriptionPrevious value: -"Absolute path to the document being checked."New value: +"Absolute path to the document being checked. Give this OR candidateUrl, not both."Input schema / properties / candidateUrlAdded value: +{
+ "description": "http:/https: URL to fetch the document being checked from. Fetched LOCALLY over this machine's network (not from the Tamperlens server); http/https only, redirects re-checked, max 10 MB on the bytes received. Give this OR candidatePath, not both.",
+ "type": "string"
+}Input schema / properties / originalPath / descriptionPrevious value: -"Absolute path to the document you trust."New value: +"Absolute path to the document you trust. Give this OR originalUrl, not both."Input schema / properties / originalUrlAdded value: +{
+ "description": "http:/https: URL to fetch the trusted document from. Fetched LOCALLY over this machine's network (not from the Tamperlens server); http/https only, redirects re-checked, max 10 MB on the bytes received. Give this OR originalPath, not both.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "originalPath",
- "candidatePath"
-]inspect_document3 fields changedInput schema / properties / path / descriptionPrevious value: -"Absolute path to the document on this machine — PDF, Office document or image. Max 10 MB."New value: +"Absolute path to the document on this machine — PDF, Office document or image. Max 10 MB. Give this OR url, not both."Input schema / properties / urlAdded value: +{
+ "description": "http:/https: URL to fetch the document from. The fetch runs LOCALLY, over this machine's own network (not from the Tamperlens server), and only the bytes are sent on. Only http/https is accepted; redirects are followed but re-checked; max 10 MB, enforced on the bytes received. Give this OR path, not both.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "path"
-]triage_documentv1.31.0check_redactioncompare_documentsinspect_documentScored across 4 tools
Each tool has a clear action-object purpose: deep inspection, cheap pre-flight triage, PDF redaction verification, and original-vs-candidate comparison. The only real overlap is that check_redaction is a specialized slice of what inspect_document also covers, and triage_document vs inspect_document are two depths of the same scanning workflow, but the descriptions explain the intended routing well.
All tools follow a consistent lowercase snake_case verb_target pattern: inspect_document, triage_document, check_redaction, compare_documents. The only minor variation is pluralization on compare_documents, which is semantically natural and does not hurt predictability.
Four tools is well-scoped for a document-forensics server: one cheap intake preflight, one comprehensive deep inspection, one targeted redaction gate, and one comparison operation. Each tool has a distinct place in the workflow, and none feels redundant.
The surface covers the full relevant progression: triage to route, inspect to get detailed signals, check_redact before release, and compare to validate against an original. It also covers both document files and in images; the main gap is that check_redaction is PDF-only and there is no explicit batch/attation/report operation, but these are obstacles behind the core workflow.
Check a document for hidden text before your agent reads it. PDF, Office, RTF, HTML.
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Document forensics: tamper/AI checks, fields, tables, identity, screening, tenders, citations.
