Tamperlens용 MCP 서버 — 문서가 편집되었는지, 그 교정(red)이 유지되었는지, 그러고 모델이 읽기 안전한지 에이전트의 컨텍스트에 도달하기 전에 물어보세요.
// 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개로 늘어납니다.
도구 | 답변 |
| 작성된 후 편집된 것인가요? 원본 저장 이후 덧블은 수정, 자기 자신과 모순되는 메타데이터, 편시자 지문, 서명 커버리지와 무결성, 숨겨진 텍스트, 매크로, 이미지의 A 생성 흔적 — 것리고 파일에 독자에게가 아닌 언어 모델에게 보네는 텍스트가 들어 있는지 여부. |
| 가림(redation)이 실제로 아무것을 제거 시켰는지? 검은 상자로 테스트를 덮는 것은 사람에게만 숨길 뿐 파일에서 아무것도 제거되지 않습니다. |
| 제가 이미 갖고 있는 원본과 같은 파일이고, 변환 것 없이 그대로가 있나요? |
PDF, Word, Excel 및 PowerPoint(.Docx, .lsx, .pptx`, 그리고 매크로가 활성화된 동일계월 포함) 파일과 PNG, PNG, Web, HEIC/HEIF 및 VIF 등이를 지원합니다.
Related MCP server: @actalumen/mcp-server
문서를 읽는 대상은 두 종류입니다. And the only one of them sees the page. 추출 파이프라인은 제목, Keyword, 메타데이터, 메타데이터, 주석, 첨부 파일 이름을 읽습니다 — 소프트웨어가 읽기 위해 존재하는 필드입니다. 그런 곳에 놓는 텍스트는 읽혀자가 아니라 목종가도록 작성될 수 있습니다.
inspect_document는 에이전트가 파일을 소화하기 전에 이런 위험을 보고하며, 복구된 페이로드는 이 서버에서 무조건 생략됩니다. 이건 규정이 아닙니다: Tamperlens 보고서를 가장 먼저 읽을 대상은 방금 그 문서를 읽으려던 바로 그 모델일 것이나, 공격자가 주입한 문장을 다시 컨텍스트 에코하는 MCP 서버는 자신이 방금 감지한 공격을 완성하게 됩니다. 필드, 위리지, 단서 범주는 제공됩니다. 문장 자체는 제공되지 않습니다.
로컬 분석 없음. 모든 도구는 실행 중인 배포의 Tamperlens REST API에 대한 얇은 래퍼입니다. 여기에는 첫 번째와 어긋날 두 번째 엔진이 없습니다.
판결 없음. Tamperlens는 기반 증거와 함께 위험 신호를 보고하지 않으며", "이 문서는 사기 문서입니다."라고 결론 짓지 않습니다. 그 신호를 자체 판단 로직과 결합하세요.
문서는 모델의 컨텍스트에 절대 들어가지 않습니다. 도구는 호출자의 파일 시스템에서 경로를 받아 여기서 바이트를 읽습니다. Tool 호출에 Base64를 넣으면 모델이 아닌 바이트를 필요로 하는 서비스에 도달하기 위해 수 메가바이트의 문서가 컨텍스트 윈도우에 들어가게 됩니다.
저장되는 것은 없습니다. 파일은 API가 메모리에서 파싱한 뒤 응답과 함께 폐기됩니다.
변수 | 기본값 | 의미 |
| 없음 | 선택. 없는 경우 익명 제한 시간당 문서 10개가 적용됩니다. |
|
| 자체 배포 주소를 지정합니다. |
모든 신호에 대한 가이드 · 이 파일이 모델이 읽어도 안전한가요? · API 레퍼런스 · 보안 및 개인정보 보호 방침
MIT 라이선스. 이슈와 소스: github.com/haruodev/tamperlens-mcp. 통신 대상 엔진은 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.
