별도의 모델을 사용하여 AI 생성 텍스트의 정확성을 검증하고 PII 유출을 확인하는 외부 검증 게이트를 제공합니다.
다른 이름 mrhpython/lens-mcp, @soulfield/lens-mcp
- 스타
- 0
- Tools
- 10
- 다운로드, 30일
- —
- 최신 버전
- 1.1.1
- 마지막 커밋
- 2026년 11월 3일
- 라이선스
- MIT
Soulfield Lens MCP란?
Soulfield Lens은(는) MCP server입니다. 별도의 모델을 사용하여 AI 생성 텍스트의 정확성을 검증하고 PII 유출을 확인하는 외부 검증 게이트를 제공합니다. 10개 도구를 제공합니다. 예: validate_content, scrub_pii, lens_health.
프로젝트 README에서 생성된 요약
Soulfield Lens MCP server 정보
Soulfield Lens는 AI 모델이 생성한 텍스트를 위한 독립적인 검증 게이트 역할을 합니다. 모델이 자신의 작업물을 스스로 평가하는 일반적인 워크플로우와 달리, 이 MCP server는 별도의 모델을 사용하여 출력물의 정확성과 잠재적인 PII 유출 여부를 확인합니다. 이 서버는 로컬 stdio 경계에서 작동하며 api.soulfield.one에 있는 호스팅된 Lens API와 통신합니다. 이를 통해 저장소 접근 권한은 로컬 머신에 유지하면서 완성된 텍스트만 검토를 위해 전송하도록 보장합니다.
개발자는 두 가지 기능 계층 중 하나를 선택할 수 있습니다. Gate 계층은 일반적인 확인을 위한 validate_content 및 SSN이나 API 키와 같은 구조화된 식별자를 스캔하는 scrub_pii와 같은 도구를 제공합니다. Validator 계층은 여러 파일에 걸쳐 일관성 검사를 수행할 수 있는 validate_artifact와 같은 도구를 통해 더 깊은 수준의 로컬 오케스트레이션을 제공합니다. 이 계층을 사용하려면 lens-kit 라이브러리가 필요합니다. 시스템은 fail-closed 방식으로 설계되어, 모호하거나 불확실한 사례의 경우 조용히 통과시키는 대신 UNKNOWN 상태를 반환합니다.
활용 사례
- 1AI 출력 정확성 검증Gate 계층을 사용하여 생성된 텍스트가 특정 도메인 표준을 충족하는지 외부 검증을 수행합니다.
- 2민감 데이터 유출 방지텍스트 내의 신용카드 번호나 데이터베이스 연결 문자열과 같은 구조화된 비밀 정보 및 개인 식별자를 스캔합니다.
- 3파일 간 일관성 보장요약본의 수치 데이터가 원본 소스 파일의 데이터와 일치하는지 확인합니다.
프로젝트의 README를 바탕으로 작성되었습니다. 모든 활용 사례는 해당 내용의 인용문과 대조하여 확인합니다.
Soulfield Lens MCP 설치 방법
형식 확인: 2026년 11월 10일Claude Code에 Soulfield Lens MCP 설치
$ claude mcp add --env SOULFIELD_API_KEY=<YOUR_SOULFIELD_API_KEY> lens-mcp -- npx -y @soulfield/lens-mcpCursor에 Soulfield Lens MCP 설치
~/.cursor/mcp.json
{
"mcpServers": {
"lens-mcp": {
"command": "npx",
"args": [
"-y",
"@soulfield/lens-mcp"
],
"env": {
"SOULFIELD_API_KEY": "<YOUR_SOULFIELD_API_KEY>"
}
}
}
}VS Code에 Soulfield Lens MCP 설치
.vscode/mcp.json
{
"servers": {
"lens-mcp": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@soulfield/lens-mcp"
],
"env": {
"SOULFIELD_API_KEY": "<YOUR_SOULFIELD_API_KEY>"
}
}
}
}Claude Desktop에 Soulfield Lens MCP 설치
claude_desktop_config.json
{
"mcpServers": {
"lens-mcp": {
"command": "npx",
"args": [
"-y",
"@soulfield/lens-mcp"
],
"env": {
"SOULFIELD_API_KEY": "<YOUR_SOULFIELD_API_KEY>"
}
}
}
}Codex에 Soulfield Lens MCP 설치
~/.codex/config.toml
[mcp_servers.lens-mcp] command = "npx" args = ["-y", "@soulfield/lens-mcp"] [mcp_servers.lens-mcp.env] SOULFIELD_API_KEY = "<YOUR_SOULFIELD_API_KEY>"
Gemini CLI에 Soulfield Lens MCP 설치
~/.gemini/settings.json
{
"mcpServers": {
"lens-mcp": {
"command": "npx",
"args": [
"-y",
"@soulfield/lens-mcp"
],
"env": {
"SOULFIELD_API_KEY": "<YOUR_SOULFIELD_API_KEY>"
}
}
}
}Soulfield Lens MCP 도구 10
README에서 감지됨validate_contentscrub_piilens_healthvalidate_artifactlens_consistency_leakslens_consistency_numberslens_consistency_markerslens_catches_relevantlens_catches_addlens_catches_stats
| validate_content | — | |
| scrub_pii | — | |
| lens_health | — | |
| validate_artifact | — | |
| lens_consistency_leaks | — | |
| lens_consistency_numbers | — | |
| lens_consistency_markers | — | |
| lens_catches_relevant | — | |
| lens_catches_add | — | |
| lens_catches_stats | — |
구성
SOULFIELD_API_KEY비밀API key for validate_content and scrub_pii. Get one free, self-serve, no card, at https://api.soulfield.one/pricing#signup. lens_health needs no key.
SOULFIELD_API_BASELens API base URL. Use https://api.soulfield.one for the hosted service.
| 이름 | 설명 | 유형 |
|---|---|---|
| SOULFIELD_API_KEY | API key for validate_content and scrub_pii. Get one free, self-serve, no card, at https://api.soulfield.one/pricing#signup. lens_health needs no key. | 비밀 |
| SOULFIELD_API_BASE | Lens API base URL. Use https://api.soulfield.one for the hosted service. |
자동 검사
2026년 11월 13일에 실행됨전체 보고서 →자동 검사를 통과했습니다. 이는 보안 감사가 아닙니다. 코드를 직접 읽고 서버에 필요한 최소한의 권한만 부여하십시오. 검사 방식
- 소스 저장소 연결 및 접근 가능통과
- 오픈 소스 라이선스 (OSI)통과
- 최근 1년 내 커밋 또는 릴리스통과
- 패키지 이름이 인기 패키지와 유사하지 않음통과
- 원격 엔드포인트가 HTTPS 사용검사되지 않음
- 파괴적인 도구에 라벨 표시됨통과
- 모델에 대한 숨겨진 지침 없음통과
- 패키지와 의존성에 심각한 보안 권고 없음통과
README
GitHub에서 보기Soulfield Lens — MCP server
Long jobs can use validation_submit followed by validation_receipt on a
fresh MCP connection. Save the returned job ID with the candidate SHA-256 locally.
Retrieve that ID after a polling timeout; do not submit the content again.
Pending, failed, expired and incomplete jobs confer no clearance. An uncertain
submission without a returned ID must not be automatically retried. The existing
validate_content tool is unchanged. See test/validation-jobs.test.cjs for
offline recovery and Rights-preservation fixtures.
Outside-in validation for AI-generated text, as an MCP tool.
Every AI tool asks the same model that wrote the answer whether it's any good. It says yes. The Soulfield Lens is outside-in: a separate model runs a fixed gate over your output. It checks text — it doesn't write it. This package puts that gate inside Claude Code, Cursor, and any other MCP-compatible agent, so output can be validated on the path where it's generated.
The gate is fail-closed: a borderline case returns UNKNOWN, never a silent pass. There is no generation step, so it can't fabricate claims of its own — only check. It can still be wrong about a judgment; that is exactly why borderline cases return UNKNOWN instead of a confident yes.
This is a local stdio boundary around the hosted Lens API (api.soulfield.one). It keeps repository access on the caller's machine and sends only the finished artifact text to the API gate. A scrub also sends the lines of your own identity file (LENS_PUBLIC_IDENTITY_FILE) that occur in that text, so they are not redacted.
It exposes two tiers. The gate tier (3 tools) needs nothing but an API key. The validator tier (7 tools) adds one local orchestration entry point plus the optional lens-kit cross-file checks and defect memory that the single-document gate cannot see. Skip local evidence inputs and the gate tier works exactly as before.
Try it before you install anything
The keyless demo endpoint runs the same gate — a few runs a day per IP, no signup:
curl -s https://api.soulfield.one/v1/demo \
-H 'content-type: application/json' \
-d '{"text": "<paste the AI output you are about to ship>"}'
Install
npm install -g @soulfield/lens-mcp
Or run without installing: npx @soulfield/lens-mcp.
Claude Code
claude mcp add soulfield-lens \
-e SOULFIELD_API_BASE=https://api.soulfield.one \
-e SOULFIELD_API_KEY=<your-key> \
-- npx @soulfield/lens-mcp
Any MCP client (JSON config)
{
"mcpServers": {
"soulfield-lens": {
"command": "npx",
"args": ["@soulfield/lens-mcp"],
"env": {
"SOULFIELD_API_BASE": "https://api.soulfield.one",
"SOULFIELD_API_KEY": "<your-key>"
}
}
}
}
Production calls need an API key — request one at hello@soulfield.one. lens_health works without one.
Tools
Gate tier — hosted API, works out of the box
| Tool | What it does | Auth |
|---|---|---|
validate_content |
Runs the outside-in gate over text. Returns pass/fail, score, per-dimension results, and violation details with reasoning. Optional domain (general, finance, marketing, legal, seo, agency) and context (audience/purpose). |
key |
scrub_pii |
Server-side scan for structured PII and secrets — emails, UK/US phone numbers, credit-card numbers, US SSNs, UK NI/UTR numbers, database connection strings, and common API-key/credential patterns. Returns scrubbed text (each match replaced by a type marker) plus findings. Pattern-based, no LLM call. Targets structured identifiers — it does not detect personal names or free-form PII, and structured-format coverage is best-effort, not exhaustive. | key |
lens_health |
Checks the Lens API is up. Returns status and version. | none |
Validator tier — local; consistency checks require lens-kit
Version note: the validator tier lands in 1.1.0. If
npm view @soulfield/lens-mcp versionstill reports1.0.0, the registry has not caught up with this repo yet andnpx @soulfield/lens-mcpwill give you the three gate-tier tools only. Install from source in the meantime.
Artifact orchestration:
validate_artifactlands in 1.2.0. Its bounded local evidence search is built into this MCP package. Requested consistency checks still requirelens-kit.
Side effect worth knowing: every validator-tier call appends a row to
RUNS.mdin its working directory — that is the kit's run ledger, by design. The directory is thecwdargument, or the server's own cwd if you omit it, so passcwdexplicitly if you care where the ledger lives. Sensitive flag values are redacted in the row (--deny <redacted>), so deny terms do not land on disk.
Prerequisite: pip install lens_kit (Apache-2.0, github.com/mrhpython/lens-kit), or set LENS_KIT_BIN to its path. Without it these six tools return UNKNOWN with an error — never a silent pass. No API key needed: they run locally and make no LLM call.
Why they run locally and not on the hosted API: they take file paths off your disk. A hosted endpoint that accepted arbitrary local paths would be a file-disclosure vector, not a feature. On stdio the paths are your own machine, so the capability is safe here and only here — and for that reason it will not be added to the hosted API.
| Tool | What it does | Exit semantics |
|---|---|---|
validate_artifact |
Reads one local artifact, searches only explicitly permitted evidence roots, runs requested consistency checks, and sends only the artifact text to the API gate. It labels the result gate-only or evidence-preflight+gate. A literal match is a source location, not proof; a separate validator agent must read and adjudicate it before issuing a full-validator verdict. |
consistency violation → FAIL; incomplete evidence/check error → UNKNOWN; otherwise PENDING_AGENT_REVIEW |
lens_consistency_leaks |
Scans files for deny-list terms (case-insensitive literal). Run on every customer-facing file before an irreversible publish: catches a real client name, an internal codename or a banned absolute surviving into shipped copy. A credential scanner will not find these, because nothing here is a credential. Negation-blind: a banned phrase quoted in order to disclaim it matches identically to the same phrase asserted. | hit proves the string is present — adjudicate the verdict |
lens_consistency_numbers |
Checks every numeric literal in a summary actually appears in the body it summarizes. Catches the invented figure. Tripwire: literal matching only, no derived arithmetic, and a figure cited as superseded ("supersedes the ~471 estimate") flags exactly like a stale one. Review, don't auto-trust. | violation / clean |
lens_consistency_markers |
Checks evidence markers in a source survive into every rendered output — the caveat or citation dropped between formats. Case-SENSITIVE, unlike leaks above: TRIPWIRE will not match Tripwire and reads as dropped when nothing was. Tripwire: a deliberate subset render also under-counts legitimately. |
violation / clean |
Choosing deny terms and markers. These three are tripwires, not oracles — on a live run over this project's own copy they produced six flags and zero true defects, across three distinct false-positive classes (negation, superseded-figure, casing). That is the designed behaviour, and it is why the doctrine is adjudicate, never auto-apply. Deny terms work best as strings that are wrong in every context — a real client name, an internal codename — rather than claims you do not make, which legitimately appear inside disclaimers. Markers work best when their casing is stable across source and render.
| lens_catches_relevant | Reads the defect bank before you validate: prior named defects for an artifact type, most-recurrent first. Patterns at threshold are marked [PROMOTE] — they recur often enough to deserve a fixed check. | — |
| lens_catches_add | Records a named defect so it is caught next time: what was wrong, the general pattern, the forward rule. Routine passes are rejected by design — only real defects. | — |
| lens_catches_stats | Per-pattern recurrence counts with promote suggestions. Tells you what to harden next. | — |
The two tiers are complementary, not alternatives. The gate has no tools and no file access — that is precisely what makes it an independent check, and it is also why it cannot see a contradiction spread across two files. The validator tier sees the disk; the gate owns the score. Pair them: gather substrate evidence with the local tools, hand the text to the gate, and never argue a gate FAIL into a PASS. Full protocol: docs/VALIDATOR-AGENT.md.
One local entry point
validate_artifact makes the boundary explicit in one call:
{
"artifact_path": "output/candidate.md",
"evidence_roots": ["reports", "output/proof"],
"evidence_queries": [
{
"claim": "measured-result",
"query": "113/113 rows scored",
"case_sensitive": true
}
],
"domain": "agency",
"context": "Internal technical handoff"
}
The response includes evidence_scope, files_read, searches_and_commands, claims_verified, and claims_unverified. claims_verified is deliberately empty: grep proves that text exists at a source location, not that the claim is true. The separate validator agent must read the located evidence, reason across the files, and attach the final full-validator receipt.
Evidence file contents and local absolute paths are never added to the API request. Directory searches skip .git, node_modules, symlinks, and binary files and fail closed when configured safety limits are exceeded.
What you get per run: receipts — what was checked, what passed, what was held, and why. Machine-readable, not a badge. We won't hand you a guaranteed accuracy number for your data: scores don't transfer across models, datasets, and runtimes, and a tool that promises a fixed figure on data it has never seen is making the exact claim this gate exists to catch.
Long inputs
Inputs of ~4,000 characters and up are submitted as an async job and polled to completion automatically, so a single long validation never dies on a request timeout. Short inputs use the fast synchronous path. No configuration needed.
Configuration (env vars)
| Variable | Default | Purpose |
|---|---|---|
SOULFIELD_API_BASE |
http://localhost:8002 |
Lens API base URL. Use https://api.soulfield.one for the hosted service, or your own deployment. |
SOULFIELD_API_KEY |
— | Required for validate_content and scrub_pii. |
SOULFIELD_VALIDATE_TIMEOUT_MS |
180000 |
Per-request timeout for the sync path. |
SOULFIELD_VALIDATE_BUDGET_MS |
600000 |
Total wall-clock budget for the async poll loop. |
SOULFIELD_ASYNC_MIN_CHARS |
4000 |
Input length at which the async path kicks in. |
LENS_KIT_BIN |
lens-kit |
Path to the lens-kit CLI for the validator tier. Only needed if it is not on PATH. |
LENS_KIT_TIMEOUT_MS |
120000 |
Timeout for a validator-tier command. On timeout the verdict is UNKNOWN, never a pass. |
LENS_CATCHES_DIR |
~/dev/tools/lens-kit |
Default working directory for the three lens_catches_* tools, so every catch lands in one catches.jsonl. A leading ~ is expanded. Falls back to the server's cwd if the directory does not exist. A cwd argument still wins. Catches can hold verbatim snippets, so catches.jsonl must stay out of git; the lens-kit repo ignores it. |
LENS_PUBLIC_IDENTITY_FILE |
~/.config/soulfield-lens/public-identity.txt |
Your own published details (name, postal address, contact email, phone), one per line. /v1/scrub calls send the lines that occur in the text as keep, so your own details are not redacted from your outgoing work; anyone else's still are. No file: nothing is kept. |
LENS_RECEIPT_DIR |
unset | When set, each gate result from validate_content, validate_artifact and a completed validation_submit job appends one line to <dir>/receipts.jsonl (text hash, domain, context, per-lens verdicts, findings with short quotes; no document text). A leading ~ is expanded. The text, scrubbed by POST /v1/scrub, goes to <dir>/private/docs/<sha256>.txt, and <dir>/private/.gitignore holds *. The line's context, issues and quotes are scrubbed by one more /v1/scrub call; quotes are cut to 300 characters after the scrub. If a scrub fails, that text is not saved (doc_status or findings_status says so). The scrub finds structured identifiers only; names survive it. A write failure never fails the validation. |
The rest of the product
This wrapper is one of several surfaces on the same engine:
- Free one-output audit — api.soulfield.one/audit. The audit is the demo.
- Wire it in (SDK stop-hook and middleware) — api.soulfield.one/developers.
- Own it — the kit: lenses, compiler, self-improve loop, validator agent, Apache-2.0. Train it on your own data. Public repo: github.com/mrhpython/lens-kit — clone it,
pip install -e ".[dev]", and the test suite runs offline with no key. Installing it is also what activates the validator tier above.
We hold our own marketing copy to the same gate this package exposes.
License
MIT — see LICENSE. (The lens-kit product is licensed separately under Apache-2.0.)
Soulfield Lens MCP 질문
Soulfield Lens MCP를 Claude Code에 추가하려면 어떻게 하나요?
터미널에서 claude mcp add --env SOULFIELD_API_KEY=<YOUR_SOULFIELD_API_KEY> lens-mcp -- npx -y @soulfield/lens-mcp를 실행합니다. 모든 프로젝트에서 사용할 수 있게 하려면 --scope user를 추가합니다.
Soulfield Lens MCP를 Cursor에 추가하려면 어떻게 하나요?
~/.cursor/mcp.json를 열고 mcpServers 아래에 서버를 추가합니다. 위 설치 섹션에 표시된 Cursor 구성을 사용합니다.
Soulfield Lens MCP는 어떤 도구를 제공하나요?
10개 도구를 제공합니다. 예: validate_content, scrub_pii, lens_health, validate_artifact, lens_consistency_leaks.
검증 프로세스가 일반적인 LLM 자가 수정과 어떻게 다른가요?
모델이 자신의 결과물을 직접 확인하는 일반적인 방식과 달리, Soulfield Lens는 별도의 모델을 사용하여 출력물에 대해 고정된 게이트 검사를 수행합니다.
서버가 로컬 파일을 API로 전송하나요?
아니요, 호스팅된 API는 완성된 결과물 텍스트만 수신합니다. 파일 노출 위험을 방지하기 위해 로컬 파일 경로와 증거 데이터는 로컬에서 처리됩니다.
API 키 없이도 도구를 사용할 수 있나요?
네, lens_health 도구는 키 없이 작동하며, 키가 없는 데모 엔드포인트를 통해 IP당 하루에 몇 번의 실행이 가능합니다.