phi-redact-mcp
{"type": "text"}
umbryn-mcp
Ein MCP-Server, der PII/PHI aus Text entfernt, bevor dieser jemals ein LLM erreicht — selbst gehostet, fail-closed und HIPAA-bewusst.
Teams, die LLM- und Agent-Pipelines in regulierten Bereichen bauen, haben keine saubere, sofort einsetzbare Möglichkeit, PHI/PII aus einer Nutzlast zu entfernen, bevor sie die Infrastruktur eines Modellanbieters überquert. umbryn-mcp ist diese Grenze: drei MCP-Tools — redact, restore, detect — die sensible Werte in reversible Platzhalter umwandeln, vollständig in der Infrastruktur laufen, die Sie kontrollieren, und die Anfrage blockieren, wenn die Erkennung unsicher ist, anstatt Daten durchsickern zu lassen.
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.comSenden Sie den redigierten Text an das Modell; bewahren Sie die token_map lokal auf; rufen Sie anschließend restore auf, um das Ergebnis wiederherzustellen. Round-Trips sind byte-exakt und durch eigenschaftsbasierte Tests belegt.
Warum es das gibt
Die PHI/PII-Redaktions-Nische im MCP-Bereich ist real, aber unterversorgt — die bestehenden Optionen sind dünne Presidio-Wrapper ohne HIPAA-spezifische Erkennung und, entscheidend, ohne Garantie, dass ein Erkennungsfehler die Anfrage blockiert, anstatt Rohdaten stillschweigend durchzureichen. Also bauen Teams entweder ihre eigene Grenze oder senden sensible Daten an einen Anbieter und verlassen sich auf eine BAA, um das abzudecken — der Designfehler, der echte Compliance-Vorfälle verursacht.
Naiver Presidio-Wrapper | Regex in Ihrer App | Cloud-DLP-API | umbryn-mcp | |
Sofort einsetzbare MCP-Tools | manchmal | ❌ | ❌ | ✅ |
Fail-closed bei unsicherer Erkennung | ❌ | ❌ | ❌ | ✅ |
HIPAA-Identifikatoren (NPI, DEA, MBI, MRN, CLIA) | ❌ | teilweise | teilweise | ✅ |
Reversibel (Original wiederherstellen) | selten | DIY | einige | ✅ |
Selbst gehostet, null Egress | ✅ | ✅ | ❌ (sendet Daten nach außen) | ✅ |
Funktioniert mit null schweren Abhängigkeiten | ❌ (braucht spaCy) | ✅ | n/a | ✅ (Regex-Engine) |
Optionale ML-NER (Namen, Adressen) | ✅ | ❌ | ✅ | ✅ ( |
Warum es gebaut wurde: MCP wurde schnell zum Mainstream — es ist jetzt erstklassig in Claude, Cursor und ChatGPT vertreten, über Tausende von Servern — aber die PHI/PII-Redaktions-Ecke blieb ein paar ungepflegten Wrappern überlassen. Dies füllt diese Lücke mit einer einzigen ehrlichen, prüfbaren, fail-closed Grenze, die Open Source bleibt, damit die Redaktionslogik, von der Sie abhängen, vollständig einsehbar ist und keine Black Box darstellt.
Related MCP server: pii-anonymizer
Funktionen
Drei Tools, eine Grenze —
redact(→ redigierter Text + reversible Token-Map),restore(→ Original),detect(→ gefundene Entitäten, keine Veränderung).Konstruktionsbedingt fail-closed — wenn die Erkennung einen Fehler wirft oder eine Erkennung unter die Konfidenzschwelle fällt, gibt der Aufruf einen typisierten Fehler zurück. Unsicherheit blockiert; es wird nie nur das redigiert, was erkannt wurde, und der Rest durchgereicht.
HIPAA-bewusste Erkennung — prüfsummenvalidierte NPI und DEA, positionstypisierte Medicare-MBI, kontextverankerte MRN, CLIA-Laborkennungen, plus Standard-PII (E-Mail, Telefon, SSN, Kreditkarte, IBAN, IP, URL).
Null-Egress, selbst gehostet — die Standard-Engine ist reines Regex + Prüfsummen mit keinen Netzwerkaufrufen und keinen schweren Abhängigkeiten. Sie installiert sich überall, wo Python läuft.
Optionaler ML-Ausbau —
pip install "umbryn-mcp[presidio]"fügt Microsoft Presidio + spaCy fürPERSON/LOCATION-NER hinzu, transparent.Reversibel & deterministisch — kollisionssichere typisierte Platzhalter machen
restore(redact(x)) == xfür beliebige Eingaben; gleiche Eingabe + Konfiguration ergeben immer dieselbe Ausgabe.
Wann Sie es verwenden sollten (und wann nicht)
Greifen Sie zu umbryn-mcp, wenn:
Sie Gesundheits-, klinische, Finanz- oder nutzergenerierte Texte an eine Drittanbieter-LLM-API senden und PHI/PII aus der Infrastruktur und den Protokollen dieses Anbieters heraushalten müssen.
Sie eine Agent- oder MCP-Pipeline in einem regulierten Bereich bauen und eine sofort einsetzbare Redaktionsgrenze möchten, die Sie mit einem Tool-Aufruf einbinden.
Sie reversible Redaktion benötigen, damit nachgelagerte Schritte weiter funktionieren:
redact→ an das Modell senden →restore.Sie einen selbst gehosteten, Null-Egress-Detektor möchten, den Sie Zeile für Zeile prüfen können.
Sie HIPAA-spezifische Identifikatoren (NPI, DEA, Medicare-MBI, MRN, CLIA) benötigen, nicht nur Namen und E-Mails.
Greifen Sie zu etwas anderem, wenn:
Sie irreversible De-Identifikation / Anonymisierung benötigen (Tokenisierung, k-Anonymität) — die Redaktion hier ist von Design her reversibel.
Sie Nicht-Text-Daten redigieren müssen (Bilder, Audio, PDFs, Datenbankzeilen) — der Umfang ist Text.
Sie ein zertifiziertes Compliance-Produkt möchten — dies ist eine technische Kontrolle, kein Compliance-Programm (siehe Umfang & ehrliche Einschränkungen).
Sie einen transparenten Proxy möchten, der automatisch alles im Anforderungspfad bereinigt — v1 sind explizite Tool-Aufrufe; Proxy-Modus ist auf der Roadmap.
Sie garantiert 100 % Recall benötigen — kein Detektor, auch dieser nicht, kann das versprechen.
Schnellstart (< 60 Sekunden)
pip install umbryn-mcp # zero heavy deps; runs immediatelyDann registrieren Sie es bei Ihrem MCP-Client.
Claude Desktop / Claude Code (claude_desktop_config.json, oder claude mcp add umbryn-mcp -- umbryn-mcp):
{
"mcpServers": {
"umbryn-mcp": {
"command": "umbryn-mcp"
}
}
}Cursor (.cursor/mcp.json) und VS Code verwenden dieselbe Form — siehe examples/ für kopierfertige Konfigurationen.
Möchten Sie auch Namens-/Adresserkennung?
pip install "umbryn-mcp[presidio]"
python -m spacy download en_core_web_lgDer Server erkennt Presidio automatisch und führt das Upgrade durch — keine Konfigurationsänderung nötig. (Setzen Sie UMBRYN_ENGINE=regex, um die abhängigkeitsfreie Engine zu erzwingen, oder =presidio, um die ML-Engine zu verlangen.)
So funktioniert es
Ein Tool-Aufruf kommt über stdio herein; der Redactor-Kern führt die konfigurierte Erkennungs-Engine aus, löst Überlappungen deterministisch auf, wendet die Fail-closed-Schwellenprüfung an und ersetzt erkannte Bereiche durch reversible typisierte Platzhalter. Nur redigierter Text soll die Grenze verlassen, die Sie betreiben.
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)]Der Redactor-Kern hängt nur von einem kleinen DetectionEngine-Interface ab — nie direkt von Presidio oder MCP. Rohdaten und die Erkennungs-Engine bleiben innerhalb der Grenze, die Sie betreiben; nur redigierter Text verlässt sie. Siehe docs/ARCHITECTURE.md und docs/THREAT_MODEL.md.
Die Tools
redact(text) → { redacted_text, token_map, entities }
Ersetzt erkannte PHI/PII durch typisierte Platzhalter wie [NPI_1]. token_map bildet jeden Platzhalter auf seinen ursprünglichen Wert ab — bewahren Sie sie lokal auf; senden Sie sie niemals an das Modell. entities listet auf, was redigiert wurde (Typ/Bereich/Score) für die Prüfung.
restore(redacted_text, token_map) → { text }
Kehrt eine Redaktion um und stellt den Originaltext exakt wieder her. Sicher auf Modellausgaben anwendbar, die die Platzhalter noch enthalten.
detect(text) → { entities, count }
Meldet die gefundenen Entitäten — Typ, Bereich, Konfidenz — ohne den Text zu verändern. Im Gegensatz zu redact zeigt es Treffer mit niedriger Konfidenz an, anstatt zu blockieren, damit Sie die Abdeckung prüfen können, bevor Sie der Grenze in einer Pipeline vertrauen.
So verwenden Sie es (eine echte Pipeline)
Das Muster ist redact → Modell → restore, wobei die Token-Map Ihre Seite nie verlässt:
Vor dem Modell bereinigen. Rufen Sie
redact(user_text)auf. Senden Sie nurredacted_textan das LLM. Bewahren Sietoken_mapin Ihrem Prozess auf — behandeln Sie sie so sensibel wie die Rohdaten und übergeben Sie sie niemals an das Modell.Lassen Sie das Modell mit Platzhaltern arbeiten. Es sieht
[NPI_1],[US_SSN_1]usw. — semantisch neutrale Tokens, über die es nachdenken und die es zurückspiegeln kann.Danach wiederherstellen. Rufen Sie
restore(model_output, token_map)auf, um die echten Werte zurück in die Modellantwort einzufügen, bevor sie Ihren Benutzer oder Ihre Datenbank erreicht.Den Block behandeln. Wenn
redacteinen[LOW_CONFIDENCE]- oder[DETECTION_ERROR]-Toolfehler zurückgibt, hat die Grenze sich geweigert, Daten durchsickern zu lassen — melden Sie das, verschärfen Sie die Eingabe oder senken Sie das Risiko, aber senden Sie den Rohtext nicht weiter.
Bevor Sie ihr in einer Pipeline vertrauen, rufen Sie detect(sample_text) auf repräsentativen (synthetischen) Daten auf, um genau zu sehen, was erkannt wird und was nicht, und passen Sie die Schwellenwerte (unten) an Ihre Risikotoleranz an.
Fail-closed, präzise
Zwei Schwellenwerte steuern jeden redact-Aufruf:
detection_floor(Standard0.35) — die Empfindlichkeitsgrenze. Signale darunter werden als Rauschen behandelt.min_confidence(Standard0.5) — die Vertrauensschwelle.
Jeder Kandidat, der die Schwelle übersteht, aber unter min_confidence liegt, versetzt den Aufruf in den Fail-closed-Modus: Er gibt einen [LOW_CONFIDENCE]-Fehler zurück, anstatt die sicheren Bereiche zu redigieren und den unsicheren durchzureichen. Engine-Fehler geben [DETECTION_ERROR] zurück. Bei jedem Fehler wird kein redigierter Text zurückgegeben. Beide Schwellenwerte sind konfigurierbar (siehe unten).
Konfiguration
Alle optional; sinnvolle Standardwerte bedeuten, dass es ohne Konfiguration läuft. Über den env-Block des Clients setzen.
Variable | Standard | Bedeutung |
|
|
|
|
| Vertrauensschwelle; Erkennungen darunter blockieren (fail closed) |
|
| Darunter wird ein Signal als Rauschen behandelt |
|
| Größere Eingaben mit einem typisierten Fehler ablehnen |
|
| spaCy-Modell für die Presidio-Engine |
|
| Strukturierten Audit-Datensatz pro |
| (nicht gesetzt) | Pfad zu einer JSON-Konfigurationsdatei (unten) |
Konfigurationsdatei
Für Einstellungen, die nicht in eine flache Umgebungsvariable passen, zeigen Sie mit UMBRYN_CONFIG auf eine JSON-Datei. Umgebungsvariablen gewinnen für die Skalarwerte oben weiterhin gegenüber der Datei, sodass Sie eine Datei ausliefern und pro Start anpassen können. Eine fehlerhafte Datei (schlechtes JSON, unbekannte Schwelle, nicht kompilierbares Regex) schlägt fail-closed beim Start fehl, anstatt stillschweigend zu degradieren.
{
// 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
}Ein kopierfertiges Beispiel liegt unter examples/umbryn_config.json.
Entitätsabdeckung
Entität | Regex-Engine (Standard) | Presidio-Engine ( |
E-Mail, Telefon, SSN, Kreditkarte, IP, URL | ✅ | ✅ |
NPI (Luhn + 80840-Prüfziffer) | ✅ | ✅ |
DEA (Prüfziffer) | ✅ | ✅ |
Medicare MBI (positionsbasiert) | ✅ | ✅ |
MRN (kontextverankert) | ✅ | ✅ |
Medicare HICN (SSN + Begünstigtencode) | ✅ | ✅ |
CLIA-Labornummer | ✅ | ✅ |
US ITIN (9XX-Bereichsstruktur) | ✅ | ✅ |
UK-NHS-Nummer (Mod-11-Prüfung) | ✅ | ✅ |
Kanadische SIN (Luhn-Prüfung) | ✅ | ✅ |
US-Führerschein (kontextverankert) | ✅ | ✅ |
IBAN (Mod-97 / ISO-7064-Prüfung) | ✅ | ✅ |
Personennamen | ❌ | ✅ (spaCy NER) |
Adressen / Orte | ❌ | ✅ (spaCy NER) |
Benutzerdefinierte Recognizer (deine Regex + Prüfziffer, per Konfiguration) | ✅ | ✅ |
Benchmark
Die Erkennungsqualität ist gemessen, nicht behauptet. Die Zahlen unten stammen von der Standard-Engine (ohne Abhängigkeiten), die gegen den synthetischen Evaluierungskorpus ausgewertet wurde — 200 generierte Dokumente, ~1.800 annotierte Textabschnitte, mit Attrappen, die die Prüfsumme nicht bestehen, als Distraktoren eingewoben, um die Präzision ehrlich zu halten. Reproduziere sie mit python eval/run_eval.py --markdown.
Entität | Precision | Recall | 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 |
\* = HIPAA-relevante Kennung, unterliegt der CI-Qualitätsgrenze. Aggregiert über die von der Qualitätsgrenze abgedeckte Menge: Präzision 0,99, Recall 1,00. Diese Grenze lässt den Build fehlschlagen, wenn der Recall unter 0,90 oder die Präzision unter 0,80 fällt. (Die 12 False Positives von NPI sind ähnlich aussehende 10-stellige Zahlen, die zufällig die Luhn/80840-Prüfziffer bestehen — eine bewusste, ausfallsichere Tendenz zur Über-Schwärzung.)
Dies sind synthetische Idealbedingungen mit sauberer Formatierung und passenden Kontextwörtern; echte Texte sind unordentlicher. Behandle das als Absicherung gegen Regressionen und als Plausibilitätsprüfung, nicht als Garantie — bewerte stets anhand deiner eigenen repräsentativen Daten.
Umfang & ehrliche Einschränkungen
Dieses Tool reduziert die PHI/PII-Exposition an einer Grenze. Es macht ein System nicht „HIPAA-konform“. Compliance ist eine Eigenschaft eines gesamten Systems und einer gesamten Organisation — ihrer Richtlinien, Verträge, Zugriffskontrollen, Audit-Haltung und Menschen — nicht einer einzelnen Bibliothek. Das Ausführen von umbryn-mcp kann Teil eines konformen Designs sein, ist aber keine Zertifizierung, keine Garantie und kein Ersatz für einen Business Associate Agreement, eine Risikobewertung oder einen Rechtsbeistand.
Konkret leistet dieses Projekt Folgendes nicht: Es garantiert keine 100%ige Erkennung (kein Detektor tut das), de-identifiziert nicht über eine reversible Schwärzung hinaus, deckt keine Nicht-Text-Daten ab und fungiert in v1 nicht als transparenter Proxy (die Schwärzung erfolgt über explizite Tool-Aufrufe, die du einbindest). Kein Detektor ist perfekt — bewerte ihn anhand deiner eigenen repräsentativen Daten, bevor du dich darauf verlässt. Siehe docs/THREAT_MODEL.md für den vollständigen Geltungsbereich, die Annahmen und die Restrisiken sowie SECURITY.md, um Probleme zu melden.
Wie du beitragen kannst
Beiträge sind sehr willkommen — dies ist ein bewusst freundlicher Ort für deinen ersten Open-Source-PR, und der Maintainer bemüht sich, schnell zu antworten.
Der einfachste Beitrag mit hohem Mehrwert: Füge einen Erkennungs-Recognizer für eine neue Kennung hinzu (eine Regex + optional einen Prüfziffer-Validator + einen Test). Das Issue-Formular „add-a-recognizer“ dient zugleich als Spezifikation, und CONTRIBUTING.md führt dich durch die sechs Schritte.
Andere gute Möglichkeiten, wie du helfen kannst: verbessere die Dokumentation, füge Testfälle oder Beispiel-Client-Konfigurationen hinzu oder greife etwas von der Roadmap auf. Stöbere in den Good-First-Issues oder eröffne ein Issue, um etwas vorzuschlagen.
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.pyDer vollständige Leitfaden — Entwicklungs-Setup, Konventionen und die No-Real-PHI-Regel für Test-Fixtures — steht in CONTRIBUTING.md. Mit deinem Beitrag stimmst du zu, dass deine Arbeit unter der MIT-Lizenz steht.
Lizenz
MIT — entspricht Presidio und maximiert die Wiederverwendung. Erstellt mit Microsoft Presidio (optional) und dem MCP Python SDK.
umbryn-mcp wird vom Team hinter Kenda entwickelt.
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