Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.mrhpython/lens-mcp

NPM · @SOULFIELD/LENS-MCP · SCANNED SEP 23

Outside-in validation gate for AI-generated text; a separate model checks LLM output, fail-closed.

Available components

+3 this week 81 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security98
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • No install/post-install scripts declared.Pass
  • 31 of 95 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
Schema Quality & AI Usability69
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 1771 tokens (~196/item across 9 items; 9 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management90
  • Stability observed for 27 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 9 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the io.github.mrhpython/lens-mcp server?

io.github.mrhpython/lens-mcp runs locally as an npm package, launched with npx -y @soulfield/lens-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

npm · @soulfield/lens-mcp

# add to Claude Code
claude mcp add mrhpython-lens-mcp -- npx -y @soulfield/lens-mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "mrhpython-lens-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@soulfield/lens-mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "mrhpython-lens-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@soulfield/lens-mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add mrhpython-lens-mcp -- npx -y @soulfield/lens-mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mrhpython-lens-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@soulfield/lens-mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add mrhpython-lens-mcp --command npx --arg -y --arg @soulfield/lens-mcp
# ~/.hermes/config.yaml
mcp_servers:
  mrhpython-lens-mcp:
    command: "npx"
    args: ["-y", "@soulfield/lens-mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "mrhpython-lens-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@soulfield/lens-mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add mrhpython-lens-mcp -t stdio -c npx -a -y @soulfield/lens-mcp
// mcp.json
{
  "mcpServers": {
    "mrhpython-lens-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@soulfield/lens-mcp"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 22 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.

  • 19 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 73 to 77. That category is still filling its 30-day observation window: 22 days of observed history at the previous scan, 23 at this one. The score rises as the window fills, whether or not the server changes.

  • 17 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.

  • 15 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.

  • 13 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.

  • 11 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.

  • 9 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.

  • 7 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 23 Sept 2026 · Analysed npm/@soulfield/lens-mcp@1.1.1

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem npm

Background: How many MCP packages publish verified provenance →

Dependencies 95 packages
Packages resolved 95
Stale 31
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 9 exposed · ~1,771 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
lens_catches_add ~235

Append a NAMED DEFECT to the defect bank so it is caught next time. Record what was WRONG, the general pattern it is an instance of, and the forward rule that prevents it — doctrine REJECTS routine passes, so only log actual defects. Set self_catch=true when the defect was a failure of your own validation discipline. This is the write half of the improvement loop: enough recurrences of a pattern promote it to a deterministic check.

NameTypeReqDescription
artifact_typestringyesArtifact type, e.g. landing-copy, research-brief
catchstringyesWhat was WRONG (the specific defect found)
cwdstringWorking directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd.
domainstringyesDomain, e.g. marketing, finance, agency
patternstringyesThe general trap this is an instance of
rulestringyesThe forward rule that prevents this next time
self_catchbooleanTrue if this was a failure of the validator's own discipline

No output schema declared.

No examples provided.

lens_catches_relevant ~238

Read the defect bank BEFORE validating: prior named defects for an artifact type, most-recurrent patterns first. This is the institutional memory that makes the gate improve over time — the recurring traps tell you where this class of artifact has failed before. Any pattern at threshold is marked [PROMOTE], meaning it recurs often enough to deserve a deterministic check. Runs the local lens-kit CLI, no LLM call. Omit artifact_type and pass all=true when the type has no history yet.

NameTypeReqDescription
allbooleanSurface every catch regardless of artifact type
artifact_typestringArtifact type to filter by, e.g. landing-copy, research-brief, content-pack
cwdstringWorking directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd.
domainstringAlso filter by domain, e.g. marketing, finance, agency
formatstringblock = paste-ready surface (default); json = raw records
thresholdintegerRecurrence threshold for [PROMOTE] lines (default 3)

No output schema declared.

No examples provided.

lens_catches_stats ~93

Per-pattern recurrence counts across the defect bank. Any pattern at or above the threshold gets a PROMOTE-to-deterministic-check suggestion — that is the signal a recurring judgment call should become a cheap fixed check instead. Use this to decide what to harden next.

NameTypeReqDescription
cwdstringWorking directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd.

No output schema declared.

No examples provided.

lens_consistency_leaks ~289

Scan customer-facing files for deny-list terms (CASE-INSENSITIVE literal match — note lens_consistency_markers is case-SENSITIVE, they differ). Deterministic, no LLM. Exit 6 on a hit. Run this on EVERY customer-facing file before any irreversible publish: it is the check that 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. IMPORTANT — a hit proves the STRING IS PRESENT, which is authoritative; it does not by itself prove a violation, because the match is NEGATION-BLIND: a banned phrase quoted in order to disclaim it ('we will not give you a guaranteed accuracy number') looks identical to the same phrase asserted. Adjudicate before acting. Deny terms should therefore be strings that are wrong in EVERY context (a real client name, an internal codename), not claims-you-do-not-make — those belong in a lens prompt.

NameTypeReqDescription
cwdstringWorking directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd.
denyarrayExtra deny terms, added to the profile's consistency.deny
filesarrayyesLocal file path(s) to scan
profilestringProfile YAML providing consistency.deny

No output schema declared.

No examples provided.

lens_consistency_markers ~261

Check that evidence markers counted in a source artifact survive into every rendered output. Deterministic, no LLM, exit 6 on a violation. Catches the caveat, citation or hedge that gets dropped between formats — the source says 'as-of 2026-04' and the rendered deck quietly does not. Matching is CASE-SENSITIVE (unlike lens_consistency_leaks, which is case-insensitive), so pick markers whose casing is stable across source and render: 'TRIPWIRE' in the source will NOT match 'Tripwire' in the render and will read as dropped when nothing was. TRIPWIRE: a deliberate subset render also under-counts legitimately. Before treating a hit as a removed caveat, grep the rendered file case-insensitively.

NameTypeReqDescription
cwdstringWorking directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd.
markersarrayExplicit marker strings (otherwise taken from the profile)
profilestringProfile YAML providing the marker set
renderedarrayyesRendered output file(s) to check against the source
sourcestringyesThe source artifact (authoritative marker counts)

No output schema declared.

No examples provided.

lens_consistency_numbers ~156

Check that every numeric literal in a summary actually appears in the body it summarizes. Deterministic, no LLM, exit 6 on a violation. Catches the invented figure — the number a summary asserts that its source never stated. TRIPWIRE, not an oracle: literal matching only, no semantic or derived arithmetic, so a legitimately computed total will flag. Review a hit, do not auto-trust it.

NameTypeReqDescription
bodystringyesThe body file the summary summarizes
cwdstringWorking directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd.
summarystringyesThe summary file (its numbers must appear in the body)

No output schema declared.

No examples provided.

lens_health ~30

Check if the Soulfield Lens API service is running and responsive. Returns status and version. No auth required.

Input schema present but exposes no named parameters.

No output schema declared.

No examples provided.

scrub_pii ~193

Scan text 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) via the hosted Lens API. Returns scrubbed text with each match replaced by a generic [REDACTED] marker (the finding TYPE — email, phone_uk, ni_number, etc. — appears only in the findings list, not in the replacement), plus that findings list. It scrubs structured identifiers only: personal NAMES survive, so scrubbed output is not anonymized. Pattern-based server-side scan, no LLM call. Targets structured identifiers — it does not detect personal names or free-form PII, and coverage of structured formats is best-effort, not exhaustive. Requires SOULFIELD_API_KEY.

NameTypeReqDescription
textstringyesThe text to scan for PII

No output schema declared.

No examples provided.

validate_content ~276

Run the 10-lens validation gate on AI-generated content. Returns pass/fail, per-lens results, violation details, and a deterministic 0-10 score derived from violation counts (10 = clean, floors at 0; computed by the API tier layer, not by the LLM — the LLM-emitted 0-100 score was removed 2026-07-30). Requires SOULFIELD_API_KEY. Supports domains: general, finance, marketing, legal, seo, agency. WIRE CONTRACT (since 2026-08-10): each lens carries status (ran|skipped|error) and passed is null whenever no verdict was produced — parse passed===false as the violation signal, never !passed. HALT SEMANTICS: Rights runs first and halts the run on a critical violation; in a halted response downstream judged lenses read passed:null/status:skipped (unknown, not clean — consciousScan is non-blocking and keeps passed:true, its status:skipped is the never-ran signal).

NameTypeReqDescription
contextstringAudience/purpose context for Relevance lens (Lens 9). Omit to skip Relevance silently.
domainstringDomain context for validation (default: general)
textstringyesThe AI-generated content to validate

No output schema declared.

No examples provided.

Common questions

What is the io.github.mrhpython/lens-mcp server?

io.github.mrhpython/lens-mcp is listed in the public MCP registry as io.github.mrhpython/lens-mcp. Outside-in validation gate for AI-generated text; a separate model checks LLM output, fail-closed. This page covers its npm package (@soulfield/lens-mcp).

Is the io.github.mrhpython/lens-mcp server safe to use?

io.github.mrhpython/lens-mcp scores 81 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 23 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.github.mrhpython/lens-mcp server expose?

io.github.mrhpython/lens-mcp exposes 9 tools: validate_content, scrub_pii, lens_health, lens_catches_relevant, lens_catches_add, and 4 more. Their descriptions and schemas cost roughly 1,771 tokens of context every time the server is loaded.

Is the io.github.mrhpython/lens-mcp server still maintained?

io.github.mrhpython/lens-mcp is still listed as active in the MCP registry. We last reached this channel on 23 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the io.github.mrhpython/lens-mcp server under?

io.github.mrhpython/lens-mcp declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.