面向 Tamperlens 的 MCA 服务器 —— 用于在文档进入你的 Agent 上下文之前，检查它是否被编辑过、它的遮盖行为是否仍然有效，以及让一个模型来读取它是否安全。
// Claude Desktop / Claude Code — claude_desktop_config.json or .mcp.json
{
"mcpServers": {
"tamperlens": {
"command": "npx",
"args": ["-y", "tamperlens-mcp"],
"env": { "TAMPERLENS_API_KEY": "tl_..." }
}
}
}无需密钥即可试用；即使没有密钥，也有一个匿名使用的额度，即每小时 10 份文档。在 tamperlens.com/account 认领一个免费密钥，就可以让额度提升到每月 50 份，并且不需要绑定任何卡片。
工具 | 回答的问题 |
| 这个文档在写完之后是否又被人编辑过了？包括：原始保存之后追加的修订、自相矛盾的元数据、编辑器指纹、签名覆盖范围与完整性、隐藏文本、没有展示的宏、图像中的 AI 生成痕迹 —— 以及该文档是否带有专门写给语言模型的文本，而不是写给读者的文本。 |
| 所说的"遮盖"是否真的删除或者化掉了内容？用黑色四边形把文字盖起来，只是让人看不见它，而对文件本身并没做任何删除。 |
| 这个文件与我现在已经持有的原始文件是否完全一样、又没有任何变化？ |
支持 PDF；Word、Excel 和 PowerPoint（.docx、.xlsx、.pptx 以及它们带宏的兄弟版本），以及 JPEG、PNG、WebP、HEIC/HEIF 与 AVIF。
Related MCP server: @actalumen/mcp-server
一份文档会被两群人阅读，而其中只有一群会看到页面本身。真正的读取管线会读取标题、关键词、XM P 通信包、加注、附件的名字——这些字段是专门设计成用"软件的方式"来读取的。被放到这些位置的文字，本来就可以被写成要让人去执行的，而不是要被人阅读的。
inspect_document 会在你的 Agent 正式摄取该文件之前把这些情况报告出来，而且这个服务器会把恢复出来的大块载荷一律略去。这并不是为了图省事：Tamperlense 报告最有可能下一个阅读者，就是那台已经打算读文档的模型本身。换句话说，如果一个 MCP 服务器把攻击者注入的那句话原样传回上下文，那它就等于完成了一次自己本来探查到的那次攻击。你拿到的，是它出现在哪个字段、什么位置、属于哪个提示"类别，而不是那句原文。
本地分析没有人在做。 这里的每个工具只是运行着 Tamperlens REST API 的一个部署上一层的薄壳。并没有一个单独这么多的一套引擎，会慢慢和前面的那个引擎产生偏差。
不下任何结论。 Tamperlens 提供的是带着证据的风险信号，而不会说"这份文档是伪抄袭的"。收到这些之后，需要你自己结合自己的业务判断决定。
文档永远不进进入模型的上下文。 工具会拿到调用者文件系统里的一份路径，并直接在这里读取字节。如果采用工具调用把 Base64 抛进去，那是相当于把几十 MB 的文档搬进上下文窗口，仅仅为了去服务一个需要"字节"而不需要"模型重点"的接口。
一切都不会被保存。 文件会让 API 在内存中读出并解析，然后当响应返回时一并丢弃。
变量 | 默认值 | 含义 |
| 无 | 可选。不设置时就照旧使用匿名额度（每小 时10份文档）. |
|
| 可改成面向自己的部署。 |
信号全方位指南 ·［这份文件模型可以安全阅读吗？ · API 参考 · 安全与隐私工程师剖面
MIT 许可。问题与源码：github.com/haruodev/tamperlens-mcpu。他身后要通信的引擎是 tamperlens.com.本仓库只包含 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...
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.
