Skip to main content
Glama
Sign In
MedOrqis MCP Server

MedOrqis MCP Server

by seotarek
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Protected Health Information (PHI) De-identifier

scrub_phi
Read-onlyIdempotent

Redacts Protected Health Information from clinical narratives by masking HIPAA identifiers, national IDs, MRNs, phone numbers, and emails before logging or external processing.

Instructions

Scans clinical narratives and de-identifies Protected Health Information (PHI), masking HIPAA Safe Harbor 18 identifiers, Egyptian National IDs (14 digits), Saudi Iqama/National IDs (10 digits), Medical Record Numbers (MRN), phone numbers, and email addresses.

When to use:

  • Sanitizing patient narratives, consultation transcripts, or discharge summaries before logging, exporting, or passing to external models or public registries.

When NOT to use:

  • Detecting adversarial prompt injections, jailbreaks, or security exploits (use scan_prompt_security instead).

  • Calculating clinical risk scores or physiological parameters (use calculate_clinical_score or check_red_flags instead).

  • Normalizing pharmaceutical brand names to generic entities (use normalize_terminology instead).

Parameter constraints & formats:

  • 'text': Unstructured clinical narrative, progress note, or dialogue string (up to 500,000 characters) containing patient identifiers to mask.

Behavioral guarantees & return states:

  • Non-LLM deterministic transformation running locally in memory using regex and Luhn checksum validation; requires no external APIs, credentials, or rate limits.

  • Token substitution: Direct identifiers are replaced with standardized masking tokens ([NATIONAL_ID_REDACTED], [PHONE_REDACTED], [EMAIL_REDACTED], [MRN_REDACTED]) while preserving clinical timeline and context.

  • Return contract: Returns scrubbed_text alongside audit_report (total_entities_detected and breakdown by type); stateless with zero disk logging or network leakage.

Input Schema

NameRequiredDescriptionDefault
textYesRaw clinical text, patient consultation note, discharge summary, or dialogue containing potential PHI identifiers to redact.

Output Schema

NameRequiredDescriptionDefault
audit_reportYesDetailed de-identification summary including count of detected entities and list of redacted identifier categories.
scrubbed_textYesPrivacy-sanitized narrative with all detected identifiers replaced with safe masking tokens.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.2
    • addedInput schema / properties / text / examples
      Added value: +[
+  "Patient Ahmed Mahmoud, Egyptian NID 29501011234567, phone +201012345678, MRN-98421 presented with acute cough"
+]
    • addedInput schema / properties / text / minLength
      Added value: +1
    • addedOutput schema / properties / audit_report / properties
      Added value: +{
+  "entities_by_type": {
+    "description": "Count breakdown grouped by identifier category (national_id, phone, email, mrn).",
+    "type": "object"
+  },
+  "total_entities_detected": {
+    "description": "Total number of PHI items successfully identified and masked.",
+    "type": "integer"
+  }
+}
    • addedOutput schema / properties / audit_report / required
      Added value: +[
+  "total_entities_detected",
+  "entities_by_type"
+]
    • addedOutput schema / required
      Added value: +[
+  "scrubbed_text",
+  "audit_report"
+]
  2. Changed2 schema fields changedv0.1.1
    • addedInput schema / properties / text / description
      Added value: +"Raw clinical text, patient consultation note, discharge summary, or dialogue containing potential PHI identifiers to redact."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "description": "Sanitized text output and de-identification audit report detailing detected and redacted PHI categories.",
+  "properties": {
+    "audit_report": {
+      "description": "Detailed de-identification summary including count of detected entities and list of redacted identifier categories.",
+      "type": "object"
+    },
+    "scrubbed_text": {
+      "description": "Privacy-sanitized narrative with all detected identifiers replaced with safe masking tokens.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds substantially more: deterministic non-LLM regex plus Luhn checksum validation, no external APIs or credentials, stateless with zero disk logging or network leakage. It also discloses what the transformation produces via concrete masking tokens rather than just declaring safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose followed by clearly labelled sections makes it scannable and every heading is purposeful. Minor redundancy: the return contract restates what the output schema already defines, and the identifier list appears twice (prose and token list).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only transformation with an output schema already present, the description covers purpose, exclusions, input format and size limit, determinism, privacy guarantees, and masking output. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds a real constraint absent from the schema: a 500,000 character upper bound and the characterization of the input as narrative/progress note/dialogue. It does not document failure modes for oversized or already-scrubbed input, so it stops short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb ("scans" / "de-identifies") and resource (PHI in clinical narratives), and enumerates exactly which identifier classes are masked (HIPAA Safe Harbor 18, Egyptian NID 14-digit, Saudi Iqama 10-digit, MRN, phone, email). An agent can distinguish this from normalize_terminology or scan_prompt_security without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit "When to use" and "When NOT to use" sections, and each exclusion names the correct sibling alternative (scan_prompt_security, calculate_clinical_score, check_red_flags, normalize_terminology). The routing decision is fully determined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools