phi-redact-mcp
umbryn-mcp
Un servidor MCP que redacta PII/PHI del texto antes de que llegue a un LLM: autohospedado, con bloqueo ante incertidumbre y compatible con HIPAA.
Los equipos que construyen canalizaciones de LLM y agentes en sectores regulados no tienen una forma limpia e integrable de eliminar PHI/PII de una carga útil antes de que cruce a la infraestructura del proveedor del modelo. umbryn-mcp es ese límite: tres herramientas MCP — redact, restore, detect — que convierten valores sensibles en marcadores de posición reversibles, se ejecutan íntegramente dentro de la infraestructura que controlas y bloquean la solicitud si la detección es incierta, en lugar de filtrar datos.
redact("Patient MRN: 1234567, provider NPI 1234567893, ssn 078-05-1120, john.doe@example.com")
redacted_text (safe to send to the model):
"Patient MRN: [MEDICAL_RECORD_NUMBER_1], provider NPI [NPI_1], ssn [US_SSN_1], [EMAIL_ADDRESS_1]"
token_map (kept local, never sent to the model):
[MEDICAL_RECORD_NUMBER_1] → 1234567
[NPI_1] → 1234567893
[US_SSN_1] → 078-05-1120
[EMAIL_ADDRESS_1] → john.doe@example.comEnvía el texto redactado al modelo; mantén el token_map local; llama a restore después para rehidratar el resultado. Los viajes de ida y vuelta son exactos a nivel de byte y están demostrados con pruebas basadas en propiedades.
Por qué existe
El nicho de MCP para redacción de PHI/PII es real pero está poco atendido: las opciones existentes son envoltorios básicos de Presidio sin detección específica de HIPAA y, lo que es crítico, sin garantía de que un fallo de detección bloquee la solicitud en lugar de pasar silenciosamente los datos sin procesar. Así que los equipos o construyen su propio límite o envían datos sensibles a un proveedor y se apoyan en un BAA para cubrirlo: el error de diseño que provoca incidentes de cumplimiento reales.
Envoltorio básico de Presidio | Regex en tu app | Cloud DLP API | umbryn-mcp | |
Herramientas MCP de integración directa | a veces | ❌ | ❌ | ✅ |
Bloqueo ante detección incierta | ❌ | ❌ | ❌ | ✅ |
Identificadores HIPAA (NPI, DEA, MBI, MRN, CLIA) | ❌ | parcial | parcial | ✅ |
Reversible (restaurar original) | raramente | por cuenta propia | algunos | ✅ |
Autohospedado, cero tráfico de salida | ✅ | ✅ | ❌ (envía datos al exterior) | ✅ |
Funciona con cero dependencias pesadas | ❌ (requiere spaCy) | ✅ | n/a | ✅ (motor de regex) |
NER de ML opcional (nombres, direcciones) | ✅ | ❌ | ✅ | ✅ (extra |
Por qué se creó: MCP se generalizó rápidamente: ahora es de primera clase en Claude, Cursor y ChatGPT, en miles de servidores; pero el ámbito de la redacción de PHI/PII quedó en manos de unos pocos envoltorios sin mantenimiento. Esto llena ese vacío con un único límite honesto, auditable y con bloqueo ante incertidumbre, mantenido como código abierto para que la lógica de redacción de la que dependes sea totalmente inspeccionable en lugar de una caja negra.
Related MCP server: pii-anonymizer
Features
Tres herramientas, un solo límite —
redact(→ texto depurado + mapa de tokens reversible),restore(→ original),detect(→ entidades encontradas, sin mutación).Bloqueo ante incertidumbre por construcción — si la detección da error o cualquier detección cae por debajo del umbral de confianza, la llamada devuelve un error tipado. La incertidumbre bloquea; nunca redacta lo que puede y deja pasar el resto.
Detección preparada para HIPAA — NPI y DEA validados por suma de verificación, MBI de Medicare con tipo posicional, MRN anclado al contexto, IDs de laboratorio CLIA, además de PII estándar (correo electrónico, teléfono, SSN, tarjeta de crédito, IBAN, IP, URL).
Cero tráfico de salida, autohospedado — el motor por defecto es regex puro + sumas de verificación, sin llamadas de red ni dependencias pesadas. Se instala en cualquier lugar donde se instale Python.
Mejora de ML opcional —
pip install "umbryn-mcp[presidio]"añade Microsoft Presidio + spaCy para NER dePERSON/LOCATION, de forma transparente.Reversible y determinista — los marcadores de posición tipados a prueba de colisiones hacen que
restore(redact(x)) == xpara cualquier entrada; la misma entrada + configuración siempre produce la misma salida.
Cuándo usarlo (y cuándo no)
Recurre a umbryn-mcp cuando:
Envías texto sanitario, clínico, financiero o generado por el usuario a una API de LLM de terceros y necesitas que la PHI/PII no llegue a la infraestructura ni a los registros de ese proveedor.
Estás construyendo una canalización de agente o MCP en un sector regulado y quieres un límite de depuración integrable que se conecte con una sola llamada a una herramienta.
Necesitas redacción reversible para que los pasos posteriores sigan funcionando:
redact→ enviar al modelo →restore.Quieres un detector autohospedado y sin tráfico de salida que puedas auditar línea por línea.
Necesitas identificadores específicos de HIPAA (NPI, DEA, MBI de Medicare, MRN, CLIA), no solo nombres y correos electrónicos.
Recurre a otra opción cuando:
Necesitas desidentificación/anonimización irreversible (tokenización, k-anonimato) — aquí la redacción es reversible por diseño.
Necesitas redactar datos no textuales (imágenes, audio, PDF, filas de bases de datos) — el alcance es el texto.
Quieres un producto con cumplimiento certificado — esto es un control técnico, no un programa de cumplimiento (consulta Alcance y limitaciones honestas).
Quieres un proxy transparente que depure automáticamente todo en la ruta de solicitudes — la v1 es llamadas explícitas a herramientas; el modo proxy está en la hoja de ruta.
Exiges una recuperación del 100 % garantizada — ningún detector, incluido este, puede prometerlo.
Inicio rápido (< 60 segundos)
pip install umbryn-mcp # zero heavy deps; runs immediatelyLuego regístralo en tu cliente MCP.
Claude Desktop / Claude Code (claude_desktop_config.json, o claude mcp add umbryn-mcp -- umbryn-mcp):
{
"mcpServers": {
"umbryn-mcp": {
"command": "umbryn-mcp"
}
}
}Cursor (.cursor/mcp.json) y VS Code usan la misma estructura: consulta examples/ para ver configuraciones listas para copiar y pegar.
¿También quieres detección de nombres y direcciones?
pip install "umbryn-mcp[presidio]"
python -m spacy download en_core_web_lgEl servidor detecta automáticamente Presidio y se actualiza: no hace falta cambiar la configuración. (Establece UMBRYN_ENGINE=regex para forzar el motor sin dependencias, o =presidio para exigir el de ML).
Cómo funciona
Una llamada a herramienta entra por stdio; el núcleo Redactor ejecuta el motor de detección configurado, resuelve las superposiciones de forma determinista, aplica la comprobación del umbral de bloqueo y sustituye los segmentos detectados por marcadores de posición tipados reversibles. Solo el texto depurado debe salir del límite que ejecutas.
flowchart LR
A[MCP client<br/>Claude · Cursor · agent] -- redact / restore / detect --> B[umbryn-mcp<br/>stdio server]
B --> C[Redactor core<br/>fail-closed · reversible]
C --> D{Detection engine}
D -->|default, zero deps| E[Regex + checksums]
D -->|optional| F[Presidio + spaCy NER]
C -. scrubbed text .-> A
A -- scrubbed text only --> G[(LLM / downstream)]El núcleo Redactor depende solo de una pequeña interfaz DetectionEngine: nunca de Presidio o MCP directamente. Los datos sin procesar y el motor de detección permanecen dentro del límite que ejecutas; solo el texto depurado sale de él. Consulta docs/ARCHITECTURE.md y docs/THREAT_MODEL.md.
Las herramientas
redact(text) → { redacted_text, token_map, entities }
Reemplaza la PHI/PII detectada por marcadores de posición tipados como [NPI_1]. token_map asocia cada marcador de posición con su valor original — mantenlo local; nunca lo envíes al modelo. entities enumera lo redactado (tipo/segmento/puntuación) para auditoría.
restore(redacted_text, token_map) → { text }
Revierte una redacción y recupera el texto original exactamente. Es seguro llamarla sobre la salida del modelo que aún contenga los marcadores.
detect(text) → { entities, count }
Informa de las entidades encontradas — tipo, segmento, confianza — sin modificar el texto. A diferencia de redact, muestra los aciertos de baja confianza en lugar de bloquear, para que puedas inspeccionar la cobertura antes de confiar en el límite en una canalización.
Cómo usarlo (una canalización real)
El patrón es redact → modelo → restore, con el mapa de tokens sin salir nunca de tu lado:
Depura antes del modelo. Llama a
redact(user_text). Envía soloredacted_textal LLM. Manténtoken_mapen tu proceso: trátalo con la misma sensibilidad que la entrada sin procesar y nunca se lo pases al modelo.Deja que el modelo trabaje con los marcadores. Ve
[NPI_1],[US_SSN_1], etc.: tokens semánticamente neutros sobre los que puede razonar y que puede repetir.Rehidrata después. Llama a
restore(model_output, token_map)para devolver los valores reales a la respuesta del modelo antes de que llegue a tu usuario o a tu base de datos.Gestiona el bloqueo. Si
redactdevuelve un error de herramienta[LOW_CONFIDENCE]o[DETECTION_ERROR], el límite se ha negado a filtrar: hazlo visible, refuerza la entrada o reduce el riesgo, pero no envíes el texto sin procesar.
Antes de confiar en él en una canalización, llama a detect(sample_text) sobre datos representativos (sintéticos) para ver exactamente qué se detecta y qué no, y ajusta los umbrales (abajo) a tu tolerancia al riesgo.
Bloqueo ante incertidumbre, con precisión
Dos umbrales gobiernan cada llamada a redact:
detection_floor(por defecto0.35) — el límite de sensibilidad. Las señales por debajo se tratan como ruido.min_confidence(por defecto0.5) — el umbral de confianza.
Cualquier candidato que supere el límite pero puntúe por debajo de min_confidence pone la llamada en modo de bloqueo: devuelve un error [LOW_CONFIDENCE] en lugar de redactar los segmentos con confianza y dejar pasar el incierto. Los errores del motor devuelven [DETECTION_ERROR]. Ante cualquier error, no se devuelve texto redactado. Ambos umbrales son configurables (ver más abajo).
Configuración
Todo es opcional; los valores predeterminados razonables hacen que se ejecute sin configuración. Se configura mediante el bloque env del cliente.
Variable | Default | Significado |
|
|
|
|
| Umbral de confianza; las detecciones por debajo bloquean la llamada |
|
| Por debajo de este valor, una señal se trata como ruido |
|
| Rechaza una entrada mayor con un error tipado |
|
| Modelo de spaCy para el motor de Presidio |
|
| Emite un registro de auditoría estructurado por cada llamada a |
| (sin definir) | Ruta a un archivo de configuración JSON (abajo) |
Archivo de configuración
Para ajustes que no encajan en una variable de entorno plana, apunta UMBRYN_CONFIG a un archivo JSON. Las variables de entorno siguen teniendo prioridad sobre el archivo para los valores escalares anteriores, así que puedes distribuir un solo archivo y ajustarlo en cada lanzamiento. Un archivo mal formado (JSON inválido, umbral desconocido, regex no compilable) falla en modo bloqueado al inicio en lugar de degradarse silenciosamente.
{
// Per-entity trust thresholds override min_confidence for that type.
"entity_thresholds": { "PHONE_NUMBER": 0.7, "IP_ADDRESS": 0.9 },
// Entity types to drop entirely — never detected, never redacted.
// (A privacy trade-off you're opting into: a disabled type can leak.)
"disabled_entities": ["URL"],
// Your own recognizers, no fork required. `validator` names a built-in
// check-digit function (luhn, npi, dea, iban, nhs) — config supplies data,
// never code.
"recognizers": [
{
"entity_type": "EMPLOYEE_ID",
"regex": "\\bEMP-\\d{6}\\b",
"base_score": 0.85,
"context": ["employee", "badge"],
"context_required": false
}
],
"audit_log": true
}Hay un ejemplo listo para copiar en examples/umbryn_config.json.
Cobertura de entidades
Entidad | Motor de regex (predeterminado) | Motor de Presidio ( |
Correo electrónico, Teléfono, SSN, Tarjeta de crédito, IP, URL | ✅ | ✅ |
NPI (dígito de control Luhn + 80840) | ✅ | ✅ |
DEA (dígito de control) | ✅ | ✅ |
Medicare MBI (tipado por posición) | ✅ | ✅ |
MRN (con anclaje contextual) | ✅ | ✅ |
Medicare HICN (SSN + código de beneficiario) | ✅ | ✅ |
CLIA número de laboratorio | ✅ | ✅ |
ITIN de EE. UU. (estructura de rango 9XX) | ✅ | ✅ |
Número NHS del Reino Unido (verificación mod-11) | ✅ | ✅ |
SIN canadiense (verificación Luhn) | ✅ | ✅ |
Licencia de conducir de EE. UU. (con anclaje contextual) | ✅ | ✅ |
IBAN (verificación mod-97 / ISO 7064) | ✅ | ✅ |
Nombres de personas | ❌ | ✅ (spaCy NER) |
Direcciones / ubicaciones | ❌ | ✅ (spaCy NER) |
Reconocedores personalizados (tu regex + dígito de control, mediante configuración) | ✅ | ✅ |
Evaluación comparativa
La calidad de detección se mide, no se asume. Los números siguientes corresponden al motor predeterminado (sin dependencias) evaluado sobre el corpus de evaluación sintético — 200 documentos generados, ~1.800 spans etiquetados, con imitaciones que fallan el checksum entretejidas como distractores para mantener la precisión honesta. Reprodúcelos con python eval/run_eval.py --markdown.
Entity | Precisión | Exhaustividad | F1 | TP | FP | FN |
| 1.00 | 1.00 | 1.00 | 87 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 105 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 72 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 119 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 144 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 87 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 62 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 200 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 126 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 78 | 0 | 0 |
| 0.94 | 1.00 | 0.97 | 200 | 12 | 0 |
| 1.00 | 1.00 | 1.00 | 144 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 95 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 81 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 97 | 0 | 0 |
| 1.00 | 1.00 | 1.00 | 136 | 0 | 0 |
\* = identificador relevante para HIPAA, sujeto al control de calidad del CI. Agregado sobre el conjunto evaluado: precisión 0.99, exhaustividad 1.00. El control hace fallar la compilación si la exhaustividad cae por debajo de 0.90 o la precisión por debajo de 0.80. (Los 12 falsos positivos de NPI son números de 10 dígitos parecidos a los reales que pasan el dígito de control Luhn/80840: un sesgo deliberado y a prueba de fallos hacia el enmascaramiento excesivo).
Son condiciones sintéticas de mejor caso, con formato limpio y palabras de contexto cercanas; el texto del mundo real es más desordenado. Trata esto como una barrera de regresión y una comprobación de cordura, no como una garantía: evalúa siempre con tus propios datos representativos.
Alcance y limitaciones honestas
**Esta herramienta reduce la exposición de PHI/PII en un único punto de un sistema. No hace que un sistema «cumpla la HIPAA». Volver a cumplimiento normativo a todo un sistema y organización: sus políticas, contratos, controles de acceso, postura de auditoría y personas. No es propiedad de una única librería. Ejecutar umbryn-mcp pueden ser parte de un diseño conforme, pero la herramienta no es una certificación ni una garantía, ni un sustituto de un Acuerdo de Asociado Comercial, ni de una evaluación de riesgos, ni de legal counsel.
Concretamente, este proyecto no:
garantiza el 100 % de la detección (ningún detector es perfecto);
an describe beyond a reversible redaction;
ocupa datos no textuales;
actúa como proxy transparente en v1 (redar must call via explicit methods you integrate).
Ningún detector es perfecto: evalúa con tus propios datos representativos. Evalúa before confide in itición: more on a case by case. Consult docs/THREAT_MODEL.md para understanding the full scope and assumptions, and SECURITY.md to report incidents.
Cómo contribuir
Las contribuciones son muy bienvenidas: this place is intentionally friendly for a first open source PR, and maintainers try to respond quickly.
The easiest and high-value contribution: add a detection risible for a new identifier (a regex + an optional validator of check digit + a test). The add-a-recognizer issue form doubles as a spec, and CONTRIBUTING.md walks you through the six steps in detail.
Other good ways to help: improve documentation, add test cases or example client configurations, or tackle something from the posible roadmap. Explore good first issues or open an issue to propose something.
git clone https://github.com/Rinava/umbryn-mcp && cd umbryn-mcp
pip install -e ".[dev]"
pytest # fast invariant suite (Presidio faked, sub-second)
ruff check . && mypy src/umbryn_mcp
python eval/run_eval.pyThe full guide — development setup, conventions, and the rule of no real PHI on fixtures — is in CONTRIBUTING.md. By contributing you agree that your work is MIT-licensed.
License
License MIT-licensed — matches Presidio and maximizes reuse. Built with Microsoft Presidio (optional) and the MCP Python SDK.
umbryn-mcp is built by the team behind Kenda.
Available Tools
3 toolsdetectDetect PHI/PIIA
Report the PHI/PII entities found in text without modifying it.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to inspect |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of entities found |
| entities | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It explicitly states 'without modifying it', which signals non-destructive behavior. However, it lacks details about output format, error handling, or what entities are considered PHI/PII, leaving some behavioral ambiguity.
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 single, concise sentence of 10 words that front-loads the key purpose. Every word earns its place, with no redundancy or unnecessary detail.
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 simple tool with one parameter and an output schema (context signal), the description covers the core functionality and non-modifying behavior. It could mention expected output shape or limitations, but the presence of an output schema mitigates the need for extensive return value details.
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% with a clear parameter description 'Text to inspect'. The description adds context about PHI/PII entities, but this aligns with the tool's purpose rather than enhancing parameter understanding. The schema already sufficiently explains the parameter.
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 the tool reports PHI/PII entities without modifying text. It distinguishes itself from sibling tools 'redact' and 'restore' by explicitly noting the non-modifying nature, making its purpose unambiguous.
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 does not provide explicit guidance on when to use this tool versus the sibling tools 'redact' and 'restore'. While the context implies detection is a prerequisite for redaction, no direct usage instructions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
redactRedact PHI/PIIA
Replace PHI/PII in text with reversible typed placeholders.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to scrub |
Output Schema
| Name | Required | Description |
|---|---|---|
| entities | Yes | What was redacted, for auditing |
| token_map | Yes | placeholder -> original value; keep local, do NOT send to the model |
| redacted_text | Yes | Text with PHI/PII replaced by typed placeholders |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that redaction is reversible and uses typed placeholders, but does not elaborate on side effects, permission requirements, or output format details.
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 single, concise sentence that communicates the core functionality. It is front-loaded and free of superfluous content, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one required parameter, output schema exists), the description provides sufficient context about the redaction operation and its reversible nature. It complements the siblings without needing extra details.
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 schema covers 100% of parameters with a clear 'text' parameter description. The tool description adds minimal extra meaning beyond what the schema already 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 clearly specifies the action ('Replace'), the resource ('PHI/PII in text'), and the nature of the output ('reversible typed placeholders'). It effectively distinguishes from sibling tools 'detect' and 'restore' by implying the redaction step.
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?
No guidance is provided on when to use this tool versus its siblings ('detect' for identification, 'restore' for reversal). It omits prerequisites, exclusions, or typical workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
restoreRestore redacted textB
Reverse a redaction using its token map, recovering the original text.
| Name | Required | Description | Default |
|---|---|---|---|
| token_map | Yes | placeholder -> original value | |
| redacted_text | Yes | Text containing placeholders |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes | The rehydrated original text |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the core function without mentioning side effects, required permissions, error cases, or behavior when token map is incomplete.
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 single sentence that is clear and efficient, but it could be more structured with separate sections for purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and an output schema, the description is adequate for a simple tool, but it lacks usage guidelines and behavioral transparency, which are gaps for completeness.
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 baseline is 3. The description reuses the schema descriptions for both parameters, adding no additional meaning beyond what the schema already 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 clearly states the tool's action ('Reverse'), the resource ('a redaction'), and the method ('using its token map, recovering the original text'). This distinguishes it from sibling tools 'detect' and 'redact'.
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 implies usage when you have a redacted text and token map to restore, but it does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
detect - First observed
redact - First observed
restore
TDQS
Scored across 3 tools
Each tool has a distinct and non-overlapping purpose: detect finds entities, redact replaces them, and restore reverses the redaction. No ambiguity.
All tool names are single verbs (detect, redact, restore) following a consistent pattern, making them easily predictable.
Three tools exactly cover the full PHI redaction workflow (detect, redact, restore) without unnecessary extras or missing steps.
The tool set provides a complete pipeline: detection, redaction with reversible placeholders, and restoration. No obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
MCP server for detecting and redacting PII (Personally Identifiable Information) in PDF documents.
HealthGuard - 12-tool health/medical AI safety MCP: PII redaction, HIPAA, GDPR Art.9.
Stateless PII redaction over MCP/REST. Free ≤1000 words or $0.01/call; file upload supported.
Hosted MCP server exposing US hospital procedure cost data to AI assistants
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAn MCP proxy that pseudo-anonymizes PII before data reaches external AI providers like Claude, ChatGPT, or Gemini.18MIT
- FlicenseNot gradedqualityDmaintenanceMCP server for automatic detection and redaction of PII in text, with anonymization and deanonymization capabilities, all local processing.1-
- AlicenseAqualityCmaintenanceMCP server and CLI for detecting, redacting, and auditing PHI in medical text before it is sent to AI agents, with tools for scan, redact, audit, and validate operations.4MIT
- AlicenseAqualityCmaintenanceMCP server and CLI for detecting, redacting, and auditing PHI in medical text before it reaches AI agents.4MIT