MCP-Server für Tamperlens — fragen Sie ab, ob ein Dokument bearbeitet wurde, ob seine Schwärzungen Bestand haben und ob es für ein Modell sicher zu lesen ist, bevor es in den Kontext Ihres Agenten gelangt.
// Claude Desktop / Claude Code — claude_desktop_config.json or .mcp.json
{
"mcpServers": {
"tamperlens": {
"command": "npx",
"args": ["-y", "tamperlens-mcp"],
"env": { "TAMPERLENS_API_KEY": "tl_..." }
}
}
}Zum Ausprobieren ist kein Schlüssel erforderlich — ohne einen erhalten Sie das an nordwendige?
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...
Scan text, documents, websites, and MCP metadata for prompt injection and sensitive-data risks.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
