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
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
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 26 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
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
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
claude mcp add mrhpython-lens-mcp -- npx -y @soulfield/lens-mcp
{
"mcpServers": {
"mrhpython-lens-mcp": {
"command": "npx",
"args": [
"-y",
"@soulfield/lens-mcp"
]
}
}
} {
"servers": {
"mrhpython-lens-mcp": {
"command": "npx",
"args": [
"-y",
"@soulfield/lens-mcp"
]
}
}
} codex mcp add mrhpython-lens-mcp -- npx -y @soulfield/lens-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"mrhpython-lens-mcp": {
"type": "local",
"command": [
"npx",
"-y",
"@soulfield/lens-mcp"
],
"enabled": true
}
}
} openclaw mcp add mrhpython-lens-mcp --command npx --arg -y --arg @soulfield/lens-mcp
mcp_servers:
mrhpython-lens-mcp:
command: "npx"
args: ["-y", "@soulfield/lens-mcp"] {
"McpServers": {
"mrhpython-lens-mcp": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"@soulfield/lens-mcp"
]
}
}
} assistant mcp add mrhpython-lens-mcp -t stdio -c npx -a -y @soulfield/lens-mcp
{
"mcpServers": {
"mrhpython-lens-mcp": {
"command": "npx",
"args": [
"-y",
"@soulfield/lens-mcp"
]
}
}
} 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.
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 →
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 →
lens_catches_add Record a Catch (append to defect memory) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| artifact_type | string | yes | Artifact type, e.g. landing-copy, research-brief |
| catch | string | yes | What was WRONG (the specific defect found) |
| cwd | string | – | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. |
| domain | string | yes | Domain, e.g. marketing, finance, agency |
| pattern | string | yes | The general trap this is an instance of |
| rule | string | yes | The forward rule that prevents this next time |
| self_catch | boolean | – | True if this was a failure of the validator's own discipline |
No output schema declared.
No examples provided.
lens_catches_relevant Prior Catches (institutional defect memory) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| all | boolean | – | Surface every catch regardless of artifact type |
| artifact_type | string | – | Artifact type to filter by, e.g. landing-copy, research-brief, content-pack |
| cwd | string | – | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. |
| domain | string | – | Also filter by domain, e.g. marketing, finance, agency |
| format | string | – | block = paste-ready surface (default); json = raw records |
| threshold | integer | – | Recurrence threshold for [PROMOTE] lines (default 3) |
No output schema declared.
No examples provided.
lens_catches_stats Catch Recurrence 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.
| Name | Type | Req | Description |
|---|---|---|---|
| cwd | string | – | Working 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 Forbidden-String Leak Scan ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| cwd | string | – | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. |
| deny | array | – | Extra deny terms, added to the profile's consistency.deny |
| files | array | yes | Local file path(s) to scan |
| profile | string | – | Profile YAML providing consistency.deny |
No output schema declared.
No examples provided.
lens_consistency_markers Marker Parity (source vs rendered) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| cwd | string | – | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. |
| markers | array | – | Explicit marker strings (otherwise taken from the profile) |
| profile | string | – | Profile YAML providing the marker set |
| rendered | array | yes | Rendered output file(s) to check against the source |
| source | string | yes | The source artifact (authoritative marker counts) |
No output schema declared.
No examples provided.
lens_consistency_numbers Number Parity (summary vs body) ~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.
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | The body file the summary summarizes |
| cwd | string | – | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. |
| summary | string | yes | The summary file (its numbers must appear in the body) |
No output schema declared.
No examples provided.
lens_health Lens API Health Check ~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 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.
| Name | Type | Req | Description |
|---|---|---|---|
| text | string | yes | The text to scan for PII |
No output schema declared.
No examples provided.
validate_content 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).
| Name | Type | Req | Description |
|---|---|---|---|
| context | string | – | Audience/purpose context for Relevance lens (Lens 9). Omit to skip Relevance silently. |
| domain | string | – | Domain context for validation (default: general) |
| text | string | yes | The AI-generated content to validate |
No output schema declared.
No examples provided.
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.