Validación de fuera hacia dentro para texto generado por IA, como herramienta MCP.
Toda herramienta de IA le pregunta al mismo modelo que escribió la respuesta si es buena. Y dice que sí. Soulfield Lens es de fuera hacia dentro: un modelo separado ejecuta una compuerta fija sobre tu salida. Comprueba texto — no lo escribe. Este paquete coloca esa compuerta dentro de Claude Code, Cursor y cualquier otro agente compatible con MCP, de modo que la salida pueda validarse en el camino donde se genera.
La compuerta es de cierre ante fallos: un caso límite devuelve UNKNOWN, nunca un pase silencioso. No hay paso de generación, por lo que no puede inventar afirmaciones propias — solo comprobar. Aun así puede equivocarse en un juicio; es exactamente por eso que los casos límite devuelven UNKNOWN en lugar de un sí confiado.
Es un wrapper delgado de stdio alrededor de la API Lens alojada (api.soulfield.one). Sin modelo local, sin paso de compilación — un archivo, dos dependencias.
Expone dos niveles. El nivel de compuerta (3 herramientas) solo necesita una clave de API. El nivel de validador (6 herramientas) es opcional y solo se activa si además tienes instalada la CLI lens-kit localmente — ejecuta comprobaciones deterministas entre archivos y la memoria de defectos que la compuerta de un solo documento no puede ver. Omítelo y el nivel de compuerta funciona exactamente igual que antes.
El endpoint de demostración sin clave ejecuta la misma compuerta — unas pocas ejecuciones al día por IP, sin registro:
curl -s https://api.soulfield.one/v1/demo \
-H 'content-type: application/json' \
-d '{"text": "<paste the AI output you are about to ship>"}'Related MCP server: Arkheia Hallucination Detection MCP
npm install -g @soulfield/lens-mcpO ejecútalo sin instalar: npx @soulfield/lens-mcp.
claude mcp add soulfield-lens \
-e SOULFIELD_API_BASE=https://api.soulfield.one \
-e SOULFIELD_API_KEY=<your-key> \
-- npx @soulfield/lens-mcp{
"mcpServers": {
"soulfield-lens": {
"command": "npx",
"args": ["@soulfield/lens-mcp"],
"env": {
"SOULFIELD_API_BASE": "https://api.soulfield.one",
"SOULFIELD_API_KEY": "<your-key>"
}
}
}
}Las llamadas de producción necesitan una clave de API — solicítala en hello@soulfield.one. lens_health funciona sin una.
Tool | Qué hace | Autenticación |
| Ejecuta la compuerta de fuera hacia dentro sobre el texto. Devuelve pass/fail, puntuación, resultados por dimensión y detalles de violación con razonamiento. | clave |
| Escaneo en el servidor de PII estructurada y secretos — correos electrónicos, números de teléfono del Reino Unido/EE. UU., números de tarjeta de crédito, SSN de EE. UU., números NI/UTR del Reino Unido, cadenas de conexión a bases de datos y patrones comunes de claves de API/credenciales. Devuelve el texto depurado (cada coincidencia reemplazada por un marcador de tipo) más los hallazgos. Basado en patrones, sin llamada a un LLM. Se dirige a identificadores estructurados — no detecta nombres personales ni PII de forma libre, y la cobertura de formatos estructurados es de mejor esfuerzo, no exhaustiva. | clave |
| Comprueba que la API Lens esté activa. Devuelve estado y versión. | ninguna |
lens-kit localmenteNota de versión: el nivel de validador llega en la 1.1.0. Si
npm view @soulfield/lens-mcp versiontodavía informa1.0.0, el registro aún no se ha puesto al día con este repositorio ynpx @soulfield/lens-mcpte dará solo las tres herramientas del nivel de compuerta. Instala desde el código fuente mientras tanto.
Efecto secundario que conviene saber: cada llamada del nivel de validador añade una fila a
RUNS.mden su directorio de trabajo — ese es el libro de registro de ejecuciones del kit, por diseño. El directorio es el argumentocwd, o el cwd del propio servidor si lo omites, así que pasacwdexplícitamente si te importa dónde vive el registro. Los valores sensibles de las banderas se redactan en la fila (--deny <redacted>), de modo que los términos de denegación no acaben en el disco.
Requisito previo: pip install lens_kit (Apache-2.0, github.com/mrhpython/lens-kit), o define LENS_KIT_BIN con su ruta. Sin él, estas seis herramientas devuelven UNKNOWN con un error — nunca un pase silencioso. No se necesita clave de API: se ejecutan localmente y no hacen ninguna llamada a un LLM.
Por qué se ejecutan localmente y no en la API alojada: toman rutas de archivo de tu disco. Un endpoint alojado que aceptara rutas locales arbitrarias sería un vector de divulgación de archivos, no una funcionalidad. En stdio las rutas son de tu propia máquina, por lo que la capacidad es segura aquí y solo aquí — y por esa razón no se añadirá a la API alojada.
Tool | Qué hace | Semántica de salida |
| Escanea archivos en busca de términos de lista de denegación (literal insensible a mayúsculas). Ejecútalo en cada archivo orientado al cliente antes de una publicación irreversible: detecta un nombre real de cliente, un nombre clave interno o un término absolutamente prohibido que sobrevive en la copia publicada. Un escáner de credenciales no encontrará estos, porque aquí nada es una credencial. Ciego a la negación: una frase prohibida citada para negarla coincide de forma idéntica con la misma frase afirmada. | un acierto demuestra que la cadena está presente — adjudica el veredicto |
| Comprueba que cada literal numérico en un resumen aparezca realmente en el cuerpo que resume. Detecta la cifra inventada. Alerta: solo coincidencia literal, sin aritmética derivada, y una cifra citada como superada ("supersedes the ~471 estimate") se marca exactamente igual que una obsoleta. Revisa, no te fíes automáticamente. | violación / limpio |
| Comprueba que los marcadores de evidencia en una fuente sobrevivan en cada salida renderizada — la advertencia o cita que se pierde entre formatos. Sensible a mayúsculas, a diferencia de | violación / limpio |
Elección de términos de denegación y marcadores. Estas tres son alertas, no oráculos — en una ejecución en vivo sobre la copia de este propio proyecto produjeron seis avisos y cero defectos reales, en tres clases distintas de falsos positivos (negación, cifra superada, mayúsculas). Ese es el comportamiento diseñado, y es por eso que la doctrina es adjudica, nunca apliques automáticamente. Los términos de denegación funcionan mejor como cadenas que son incorrectas en todo contexto — un nombre real de cliente, un nombre clave interno — en lugar de afirmaciones que no haces, que aparecen legítimamente dentro de descargos. Los marcadores funcionan mejor cuando su uso de mayúsculas es estable entre la fuente y la representación.
| lens_catches_relevant | Lee el banco de defectos antes de validar: defectos nombrados previamente para un tipo de artefacto, los más recurrentes primero. Los patrones en el umbral se marcan [PROMOTE] — recurren lo suficiente como para merecer una comprobación fija. | — |
| lens_catches_add | Registra un defecto nombrado para que se detecte la próxima vez: qué estaba mal, el patrón general, la regla hacia adelante. Los pases de rutina se rechazan por diseño — solo defectos reales. | — |
| lens_catches_stats | Conteos de recurrencia por patrón con sugerencias de promoción. Te dice qué reforzar a continuación. | — |
Los dos niveles son complementarios, no alternativas. La compuerta no tiene herramientas ni acceso a archivos — eso es precisamente lo que la convierte en una comprobación independiente, y también es por lo que no puede ver una contradicción repartida entre dos archivos. El nivel de validador ve el disco; la compuerta posee la puntuación. Combínalos: reúne evidencia de sustrato con las herramientas locales, entrega el texto a la compuerta y nunca conviertas un FAIL de la compuerta en un PASS. Protocolo completo: docs/VALIDATOR-AGENT.md.
Lo que obtienes por ejecución: recibos — qué se comprobó, qué pasó, qué se retuvo y por qué. Legible por máquina, no una insignia. No te daremos un número de precisión garantizado para tus datos: las puntuaciones no se transfieren entre modelos, conjuntos de datos y entornos de ejecución, y una herramienta que promete una cifra fija sobre datos que nunca ha visto está haciendo exactamente la afirmación que esta compuerta existe para detectar.
Las entradas de ~4.000 caracteres o más se envían como un trabajo asíncrono y se consultan hasta completarse automáticamente, de modo que una única validación larga nunca muere por un tiempo de espera de solicitud. Las entradas cortas usan la ruta síncrona rápida. No se necesita configuración.
Variable | Predeterminado | Propósito |
|
| URL base de la API Lens. Usa |
| — | Requerida para |
|
| Tiempo de espera por solicitud para la ruta síncrona. |
|
| Presupuesto total de tiempo real para el bucle de consulta asíncrona. |
|
| Longitud de entrada a partir de la cual se activa la ruta asíncrona. |
|
| Ruta a la CLI |
|
| Tiempo de espera para un comando del nivel de validador. En caso de tiempo de espera, el veredicto es UNKNOWN, nunca un pase. |
Este envoltorio es una de las varias interfaces del mismo motor:
Auditoría gratuita de una salida — api.soulfield.one/audit. La auditoría es la demo.
Conéctalo (stop-hook y middleware del SDK) — api.soulfield.one/developers.
Hazlo tuyo — el kit: lentes, compilador, bucle de auto-mejora, agente validador, Apache-2.0. Entrénalo con tus propios datos. Repositorio público: github.com/mrhpython/lens-kit — clónalo, pip install -e ".[dev]", y la suite de pruebas se ejecuta sin conexión y sin clave. Instalarlo es también lo que activa el nivel de validador mencionado arriba.
Sometemos nuestro propio texto de marketing al mismo control que expone este paquete.
MIT — consulta LICENSE. (El producto lens-kit está licenciado por separado bajo Apache-2.0.)
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 | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. | |
| rule | Yes | The forward rule that prevents this next time | |
| catch | Yes | What was WRONG (the specific defect found) | |
| domain | Yes | Domain, e.g. marketing, finance, agency | |
| pattern | Yes | The general trap this is an instance of | |
| self_catch | No | True if this was a failure of the validator's own discipline | |
| artifact_type | Yes | Artifact type, e.g. landing-copy, research-brief |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the operation appends to a defect bank, that routine passes are rejected, that self_catch has a specific meaning around validator discipline, and that repeated patterns can promote to deterministic checks. It does not state output/return behavior or error handling, but for an append operation the core side effect is clearly conveyed.
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?
Three dense sentences with no filler. The core action is front-loaded, policy guidance follows immediately, and the final sentence provides useful context about the improvement loop. Every sentence 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?
The description covers purpose, policy, self-catch semantics, and the improvement-loop context. It is missing only an explicit pointer to the read-half siblings and any description of what the agent should expect after a successful append, but given 100% schema coverage and the simplicity of the operation, the remaining gaps are minor.
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 coverage is 100%, so the baseline is 3. The description adds real semantic value beyond the schema by explaining that self_catch=true means a failure of the validator's own discipline and by connecting catch, pattern, and rule to the intended defect-recording workflow. It does not add much for artifact_type or domain, but those are already self-explanatory in the schema.
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 verb and resource: 'Append a NAMED DEFECT to the defect bank so it is caught next time.' It clearly differentiates itself as the write half of the improvement loop, which distinguishes it from read-oriented siblings like lens_catches_relevant and lens_catches_stats.
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 when an actual defect is found, and explicitly warns not to log routine passes ('doctrine REJECTS routine passes'). It frames the tool as the write counterpart to the loop, but it does not explicitly name read alternatives or spell out conditions for when to use sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| all | No | Surface every catch regardless of artifact type | |
| cwd | No | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. | |
| domain | No | Also filter by domain, e.g. marketing, finance, agency | |
| format | No | block = paste-ready surface (default); json = raw records | |
| threshold | No | Recurrence threshold for [PROMOTE] lines (default 3) | |
| artifact_type | No | Artifact type to filter by, e.g. landing-copy, research-brief, content-pack |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses meaningful traits: it 'Runs the local lens-kit CLI, no LLM call' (execution mechanism and cost), returns 'most-recurrent patterns first' (ordering behavior), and explains the [PROMOTE] marker semantics. Minor gap: the schema's cwd description says catches.jsonl is both read from and written to, while the description frames this as purely a read, leaving the write side-effect ambiguous.
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 purpose is front-loaded in the first sentence, and the remaining sentences each add distinct information: history rationale, PROMOTE semantics, execution mechanism, and the parameter workaround for the no-history case. The institutional-memory sentence is slightly rhetorical but reinforces why recurrence ordering matters, so no sentence is 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?
With no output schema and no annotations, the description must carry the load, and it covers the core what (named defects), ordering, promotion marking, execution mode, and the special all=true case. The format parameter's schema descriptions ('block = paste-ready surface; json = raw records') partially compensate for the missing output schema, though the exact record shape is left unspecified.
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 baseline is 3, and the description adds value on top: it explains the artifact_type/all interaction ('Omit artifact_type and pass all=true when the type has no history yet') and gives threshold meaning beyond the schema's terse wording by tying recurrence to deterministic checks. This pushes it clearly above baseline.
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 opening sentence names a specific verb and resource — 'Read the defect bank' — plus the scope ('prior named defects for an artifact type') and ordering ('most-recurrent patterns first'). This clearly differentiates it from siblings like lens_catches_add (write), lens_catches_stats (aggregate), and validate_content (validate), and the workflow position 'BEFORE validating' pins down its role.
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 context for when to use the tool — 'Read the defect bank BEFORE validating' — and an explicit scenario: 'Omit artifact_type and pass all=true when the type has no history yet.' It stops short of naming sibling alternatives or stating when not to use it, so it has clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the threshold-based PROMOTE suggestion behavior, which is useful, but it does not disclose side effects: the schema's cwd description mentions catches.jsonl is written to, yet the main description does not clarify whether this tool mutates state or only returns analysis.
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?
Three sentences, each earning its place: the output concept, the threshold behavior with a clarifying explanation, and the intended decision use. The most important information is front-loaded and jargon is briefly unpacked.
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?
For a single-parameter stats tool with no output schema, the description adequately conveys what output to expect and why it matters. It could be more complete by defining the threshold or explicitly stating side effects, but those are minor given the schema and the overall clarity.
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% for the single optional cwd parameter, and the schema already explains the working-directory semantics and the catches.jsonl read/write behavior. The tool description adds no parameter-specific meaning, but none is needed given the schema's completeness.
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 resource (defect bank) and a specific computation (per-pattern recurrence counts), and explains the output's purpose: suggesting PROMOTE-to-deterministic-check for recurring patterns. It is clear even though it lacks an explicit verb like 'get' or 'list'.
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 explicitly says to use this tool to decide what to harden next, which gives the agent a clear decision context. It does not name alternative tools or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. | |
| deny | No | Extra deny terms, added to the profile's consistency.deny | |
| files | Yes | Local file path(s) to scan | |
| profile | No | Profile YAML providing consistency.deny |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so exceptionally: it discloses determinism, no LLM involvement, exit code 6 on hit, literal case-insensitive matching, and the important negation-blind limitation requiring adjudication before acting. This goes far beyond the schema and gives an agent realistic expectations.
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 front-loaded with the core purpose and key matching semantics, then adds usage context, a critical limitation, and actionable guidance. Every sentence carries meaningful information, and the structure makes the important caveat prominent rather than burying it.
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 having no annotations and no output schema, the description provides enough context for an agent to call this tool appropriately: when to run it, what it catches, how it behaves, how to interpret results, and how it differs from related tools. The only minor omission is the explicit success-code behavior, but 'Exit 6 on a hit' is sufficient to signal contract expectations.
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 coverage is 100%, so the baseline is 3. The description adds useful semantic context beyond the schema by explaining what kinds of deny terms are appropriate ('strings that are wrong in EVERY context'), what files should be scanned (customer-facing), and how a hit should be interpreted. This exceeds the schema-only baseline.
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 verb and resource: 'Scan customer-facing files for deny-list terms (CASE-INSENSITIVE literal match...).' It also explicitly differentiates itself from the sibling lens_consistency_markers by contrasting case-sensitivity, so an agent can distinguish this tool without opening schemas.
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 an explicit invocation rule: 'Run this on EVERY customer-facing file before any irreversible publish.' It also states what alternatives do not cover ('A credential scanner will not find these') and provides negative guidance by explaining that claims-you-do-not-make belong in a lens prompt rather than in the deny list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. | |
| source | Yes | The source artifact (authoritative marker counts) | |
| markers | No | Explicit marker strings (otherwise taken from the profile) | |
| profile | No | Profile YAML providing the marker set | |
| rendered | Yes | Rendered output file(s) to check against the source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and meets it: deterministic, no LLM, exit 6 on violation, case-sensitive matching, and two false-positive traps (case mismatch and deliberate subset rendering). The concrete TRIPWIRE example makes the matching behavior unambiguous.
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?
Core purpose is front-loaded and the paragraph stays dense with useful caveats. The 'TRIPWIRE:' sentence is cryptic and slightly interrupts the flow, preventing a 5.
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?
For a 5-parameter tool with no annotations or output schema, it covers the main behavior, exit status, matching mode, and practical verification steps. It does not state the success exit condition or the full return/result shape, and it leaves profile/marker interplay to the schema, but the description is otherwise complete enough to invoke correctly.
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 covers all 5 parameters, so baseline is 3. The description adds value beyond the schema by instructing users to choose markers with stable casing and by warning that a deliberate subset render legitimately under-counts, which directly informs how markers, source, and rendered should be used.
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 first sentence names a specific verb and resource: check that source artifact markers survive into every rendered output. The title and examples further establish it as a parity/consistency verifier, and the explicit case-sensitivity contrast with lens_consistency_leaks sets it apart from siblings.
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?
It gives clear operational context: use markers with stable casing, and verify doubtful hits case-insensitively before reporting. It names lens_consistency_leaks as the case-insensitive alternative, though it never explicitly says 'use this tool when...' or lists exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory to run in. catches.jsonl is read from and written to here. Defaults to the server's cwd. | |
| body | Yes | The body file the summary summarizes | |
| summary | Yes | The summary file (its numbers must appear in the body) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers: it discloses deterministic matching, no LLM usage, exit code 6 on violation, literal-only matching with no semantic or derived arithmetic, and the caveat that legitimately computed totals will flag. This gives the agent an unusually complete picture of the tool's behavior and limitations.
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 and front-loaded, starting with the core check, then adding determinism, exit behavior, purpose, limitation, and a review caution. Every sentence adds distinct information, and there is no filler.
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 is complete for a tool with no annotations and no output schema: it covers what is checked, how it behaves, what exit code signals a violation, what its limitations are, and how the agent should handle results. The schema covers parameter details and the catches.jsonl side effect, so nothing critical is missing.
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 the summary, body, and cwd parameters well. The tool description reinforces the relationship between summary and body numbers but does not add parameter-level detail beyond what the schema provides.
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 and resource: check that every numeric literal in a summary appears in the body it summarizes. It clearly distinguishes the tool from siblings by focusing on numeric literal parity with deterministic behavior and exit 6 on violation.
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 provides clear operational context: it is deterministic, uses no LLM, and is a tripwire rather than an oracle. It explains when the result may be a false positive and tells the agent to review hits, though it does not explicitly compare against sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the Soulfield Lens API service is running and responsive. Returns status and version. No auth required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description fully carries the burden of disclosure. It states that no auth is required and that it returns status and version, and the verb 'check' clearly implies a non-mutating read-only operation. It could additionally mention timeouts or error behavior, but for a simple health check the provided transparency is solid.
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 three short sentences, each carrying distinct value: what the tool does, what it returns, and its authentication requirement. No extraneous words or repetition.
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?
For a zero-parameter health-check tool with no output schema, the description covers all essentials: purpose, return content (status and version), and auth. There are no missing details that would prevent an agent from invoking it correctly.
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 tool has zero parameters, and the schema is trivially 100% covered. With no parameters to document, the description does not need to provide additional semantics, so the baseline score of 4 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 clearly states a specific verb ('Check if') and a specific resource ('the Soulfield Lens API service'), and tells what it returns. This distinguishes it sharply from all sibling tools, which deal with content validation, PII scrubbing, or lens consistency.
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 tool's purpose is self-evident as a health check, so the context for use is clear: verify that the Soulfield Lens API is up and responsive. It does not explicitly discuss alternatives or exclusions, but there are no similar sibling tools that could be confused with this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to scan for PII |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and succeeds: it discloses that replacement markers are generic [REDACTED], that finding types are only in the findings list, that names survive, that the scan is pattern-based server-side with no LLM call, that coverage is best-effort, and that SOULFIELD_API_KEY is required. This is unusually transparent behavioral disclosure.
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 dense and front-loaded, with the core scan behavior stated first and critical caveats (names survive, best-effort, API key) following. There is minor redundancy between 'scrubs structured identifiers only' and 'targets structured identifiers', which prevents a perfect score.
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?
For a one-parameter tool with no output schema, the description is nearly complete: it covers input, output behavior, limitations, auth requirement, and execution model. It lacks precise structure for the findings list, but that does not hinder selection or invocation.
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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema's generic 'The text to scan for PII' by specifying which structured categories the text parameter is scanned for and clarifying that names/free-form PII will not be matched. This modestly exceeds the baseline.
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 ('Scan'), a specific resource ('text' via 'hosted Lens API'), and the exact class of objects detected (structured PII and secrets). It clearly differentiates itself from the validation/consistency-focused sibling tools by emphasizing scrubbed output with [REDACTED] markers and a findings list.
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 context for when the tool is appropriate: structured identifiers and secrets, not personal names or free-form PII. It explicitly excludes use cases where names must be removed and warns coverage is best-effort. It does not name alternative tools, but no direct scrubbing alternative appears among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| text | Yes | The AI-generated content to validate | |
| domain | No | Domain context for validation (default: general) | |
| context | No | Audience/purpose context for Relevance lens (Lens 9). Omit to skip Relevance silently. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the deterministic score semantics (10 = clean, floors at 0, computed by the API tier not the LLM), the precise wire contract (passed===false as the violation signal, never !passed), and halt semantics for Rights and consciousScan. This is far more transparent than a generic 'validates content' statement.
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 a dense paragraph covering purpose, outputs, score computation, authentication, domains, wire contract, and halt semantics — every sentence carries essential information and the core action is front-loaded. However, the contract and halt rules are packed into long sentences without visual structure like bullets, making it slightly harder to parse than necessary.
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?
This tool has no output schema and no annotations, so the description must explain return values and edge cases; it does. It covers pass/fail, per-lens results, violations, the 0-10 score, API key requirement, supported domains, the status/passed wire contract, and halt semantics. Nothing an agent needs for correct invocation and result interpretation is missing.
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 baseline is 3. The description's domain list mirrors the schema enum exactly and adds no new parameter meaning. The 'context' parameter semantics come from the schema description (Relevance lens, Lens 9), not from the tool description. Thus the description adds no value beyond the schema for parameters.
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 uses a specific verb and resource: 'Run the 10-lens validation gate on AI-generated content.' It clearly states what the tool does and lists its outputs (pass/fail, per-lens results, violation details, 0-10 score). The '10-lens' framing distinguishes it from sibling single-lens tools like lens_catches_relevant, even though no sibling is explicitly named.
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 prerequisites (requires SOULFIELD_API_KEY) and supported domains, which helps an agent know when it can be used. However, it never explicitly tells an agent when to choose this aggregate validation gate over a sibling single-lens tool, nor does it state exclusions. Usage must be inferred from the '10-lens validation gate' framing rather than being directly guided.
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. Dates show when Glama detected each change.
v1.1.1lens_catches_addlens_catches_relevantlens_catches_statslens_consistency_leakslens_consistency_markerslens_consistency_numberslens_healthscrub_piivalidate_contentEach tool has a distinct function: main validation, PII scrubbing, health check, three deterministic consistency checks, and defect-bank operations. The main confusion risk is lens_consistency_leaks vs lens_consistency_markers, which sound alike but are clearly separated by case-sensitivity and purpose.
The set mixes verb-initial names like validate_content and scrub_pii with a lens_-prefixed family like lens_consistency_* and lens_catches_*. Within the lens_ families naming is consistent, but the overall convention is not uniform enough for a single predictable pattern.
Nine tools is well-scoped for a validation-focused server covering gate validation, PII scrubbing, consistency checks, health, and defect-bank memory. Each tool has a clear role and none feels redundant or extraneous.
Core workflows are covered: validate content, scrub PII, run deterministic consistency checks, check service health, and read/add to the defect bank. Minor gaps include no update/delete for defect-bank entries and no tool to manage the deny-list used by lens_consistency_leaks, but these are workable limitations.
Free mechanical checks for AI text: unnamed counts, dangling references, bad arithmetic, misquotes.
Agentic code review, no signup to try: reality gates + frontier-model review, with veto.
Deterministic trust gate for AI output: leaked-secret, prompt-injection & PII in one call.
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrhpython/lens-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
