What can you do with this server?

This server is a local-first MCP tool that catches PHI in source code before it reaches LLMs, logs, or analytics. * redact_suggest: Detect PHI-shaped values (SSN, MRN, DOB, name, phone, email) in a raw text snippet and get a redacted version plus detected items with confidence scores. * scan_code: Scan a local source directory for sensitive identifiers (patient, diagnosis, dob, ssn, mrn, etc.) appearing on the same line as risky sinks like OpenAI/Anthropic calls, console.log, logger, winston, pino, .track(), or Sentry capture calls. * Run locally over stdio: No code or detected values are sent anywhere; works entirely on your machine. * Works across languages: Scans TypeScript, JavaScript, TSX/JSX, Python, and Go files, while skipping build/output directories and dotfiles. * Quiet by design: Ignores whole-line comments and only flags same-line identifier+sink combinations, keeping false positives low. * Supports verification: Run fixture tests, typecheck, smoke test, or drive the tools via the MCP Inspector.

Which integrations are available for this server?

Detects potential PHI leakage in source code that passes sensitive-looking identifiers into OpenAI API calls, and helps redact such text via the redact_suggest tool. Detects potential PHI leakage in source code that passes sensitive-looking identifiers into pino logger calls, flagging risky log statements before they ship. Detects potential PHI leakage in source code that passes sensitive-looking identifiers into PostHog analytics tracking calls such as .track(). Detects potential PHI leakage in source code that passes sensitive-looking identifiers into Sentry error-reporting calls such as captureException, captureMessage, and capture.

How do I use phi-guard-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@phi-guard-mcp scan my codebase for PHI leaks before I push" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

phi-guard-mcp

by Abidit

Overview Schema Related Servers Score Discussions

TypeScript

Local

phi-guard-mcp

npm version npm downloads License: MIT

A local-first MCP server that catches PHI (protected health information) flowing into LLM prompts, log statements, and analytics calls — in your source code, before it ships.

It runs entirely on your machine over stdio. No code, no snippets, and no detected values are ever sent anywhere.

Why

The risky moment in a healthcare codebase is rarely the database. It's the line where a patient record gets interpolated into a prompt, a console.log, or an analytics event. Those lines look harmless in review and never show up in infrastructure scanning, because nothing is misconfigured — the code is just doing what it says.

Related MCP server: phi-guard-mcp

Tools

`redact_suggest`

Takes a raw text snippet — a log line, a prompt, an error message — detects PHI-shaped values, and returns a redacted version alongside what it found.

Input

{ "text": "Patient John Doe (MRN-12345), DOB: 01/01/1980" }

Output

{
  "redacted": "Patient [NAME] ([MRN]), [DOB]",
  "detected": [
    { "type": "mrn",  "confidence": 0.9,  "start": 18, "end": 27 },
    { "type": "dob",  "confidence": 0.85, "start": 30, "end": 45 },
    { "type": "name", "confidence": 0.8,  "start": 8,  "end": 16 }
  ]
}

The matched values are not echoed back by default, and neither is the unredacted original. A tool result flows straight into the context of whatever model called it, so repeating the raw PHI there would undo the point of the tool. start/end are offsets into the original text, which is enough to locate a match without restating it.

Pass includeMatchedValues: true when you genuinely need the raw values (a local CLI, a test harness) and detected[].value plus original come back:

{ "text": "Patient John Doe (MRN-12345)", "includeMatchedValues": true }

Patterns and their confidence scores:

Type	Confidence	Matches
`ssn`	0.95	`123-45-6789`
`mrn`	0.90	`MRN-12345`, `MRN: 12345`
`dob`	0.85	`DOB: 01/01/1980`, `born 3/14/75`
`name`	0.80	`Patient John Doe` (captures `John Doe`)
`phone`	0.75	`555-867-5309`, `(555) 867 5309`
`email`	0.70	`jane.roe@example.com`

The patterns start deliberately narrow. A false positive that trains someone to ignore the tool is worse than a missed match.

`scan_code`

Walks a directory and flags lines where a sensitive-looking identifier (patient, diagnosis, dob, ssn, mrn, birthdate, medicalrecord) appears on the same line as a risky sink (openai, anthropic, bedrock, console.log/error/warn, logger., winston, pino, .track(, and capture( / captureException( / captureMessage().

Whole-line // and # comments are skipped, so a file that discusses PHI handling in prose doesn't trip the scanner on its own documentation.

Given the operative lines of test/fixtures/leaky-example.ts:

const prompt = await openai.responses.create({ input: `Patient: ${patient.name}, diagnosis: ${patient.diagnosis}` });
console.log("Sending patient prompt to LLM:", prompt);

Input

{ "path": "/abs/path/to/repo/test/fixtures" }

Output — excerpt. The full fixtures directory returns 8 findings, because it also holds the positive fixtures described under Tested against.

[
  {
    "file": "test/fixtures/leaky-example.ts",
    "line": 7,
    "severity": "high",
    "issue": "Sensitive-looking identifier passed to a risky sink (LLM call, logger, or analytics)",
    "snippet": "const prompt = await openai.responses.create({ input: `Patient: ${patient.name}, diagnosis: ${patient.diagnosis}` });"
  },
  {
    "file": "test/fixtures/leaky-example.ts",
    "line": 8,
    "severity": "high",
    "issue": "Sensitive-looking identifier passed to a risky sink (LLM call, logger, or analytics)",
    "snippet": "console.log(\"Sending patient prompt to LLM:\", prompt);"
  }
]

Scans .ts, .js, .tsx, .jsx, .py, .go. Skips node_modules, dist, build, coverage, out, .next, .turbo, and dotfiles.

snippet is the offending line with any literal PHI masked, for the same reason redact_suggest withholds matched values: the finding is going into a model's context. Identifier names like patient.diagnosis are not literal values, match no PHI pattern, and stay visible — they are the actionable part.

Both conditions must hold on the same line. That is what keeps it quiet: on this repo's own source — which is dense with the words patient, diagnosis, mrn, and ssn inside its pattern definitions — it reports zero findings.

Tested against

7 out of 7 real leak patterns detected, across 5 different sinks (OpenAI, Anthropic, Sentry, Winston, PostHog/analytics) and 2 languages (TypeScript, Python) — including snake_case identifiers (patient_name, patient_diagnosis), which a naive word-boundary regex misses and which is the dominant naming convention in Python and Go, and a hardcoded-literal fixture that verifies scan_code masks literal PHI out of the snippet it returns.

0 false positives across 5 clean-code fixtures, including code that discusses PHI policy in comments and prose without ever leaking it, and code that legitimately handles patient records without sending them anywhere risky.

1 documented limitation: detection is line-based, so a sensitive value assigned on one line and used in a risky call several lines later isn't currently caught. This is a known scope boundary, not a bug — see What this is NOT below.

Full test fixtures live in test/fixtures/ if you want to verify any of this yourself rather than take it on faith:

npm test

The suite asserts both directions: every file under positive/ must produce at least one finding, and negative/ must produce exactly zero. A miss on either side fails the run.

What this is NOT

Not a hosted service. It is a local stdio process. There is no backend, no account, and no telemetry. Your code never leaves your machine.
Not a HIPAA certification, audit, or compliance attestation. Passing a scan_code run proves nothing to a regulator. It is a linter for a specific class of mistake, not evidence of compliance. Treat a clean result as "these particular patterns didn't fire", never as "this codebase is HIPAA-safe".
Not a competitor to Prowler, AWS Config, or cloud posture tools. Those scan infrastructure and configuration. This reads source code and finds a different class of problem. They are complementary; this replaces neither.
Not exhaustive. Regex-based detection has a real false-negative rate. It will not catch PHI in a variable it can't name-match, or values arriving from an external call.
Not able to follow a value across lines. The identifier and the sink have to appear on the same line. Assigning patient.diagnosis to a local variable and logging that variable three lines later produces no finding — there is a worked example in test/fixtures/known-limitations/. Real dataflow analysis is out of scope for v1; this is a deliberate boundary, and the fixture exists so the gap stays visible rather than forgotten.
Not fully comment-aware. Only whole-line // and # comments are skipped. Block comments (/* ... */) and trailing end-of-line comments are still scanned, so a sink keyword sitting inside one of those can produce a finding even though nothing executes.

Setup

Requires Node.js 18+.

git clone https://github.com/Abidit/phi-guard-mcp.git
cd phi-guard-mcp
npm install
npm run build

dist/ is gitignored, so npm run build is required after cloning — the MCP config below points at the compiled output.

Claude Code

Add .mcp.json to your project root, using the absolute path to your clone:

{
  "mcpServers": {
    "phi-guard": {
      "command": "node",
      "args": ["/absolute/path/to/phi-guard-mcp/dist/index.js"]
    }
  }
}

Restart Claude Code, or run /mcp and reconnect phi-guard. A rebuild alone will not reach an already-running stdio process.

Verifying

npm test          # fixture suite: positive, negative, known limitations
npm run typecheck # src/ and test/ under strict mode
npx tsx test/smoke.ts

Or drive it through the official Inspector without a browser:

npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list
npx @modelcontextprotocol/inspector --cli node dist/index.js \
  --method tools/call --tool-name redact_suggest \
  --tool-arg text="Patient John Doe (MRN-12345)"

The server declares only the tools capability, so resources/list and prompts/list correctly return -32601 Method not found. The Inspector UI probes all three regardless and shows those two in red — expected, not a fault.

License

MIT — see LICENSE.

Mcp Server Approved

Listed on mcpservers.org

Available Tools

2 tools

redact_suggestA

Given a raw text snippet (a log line, a prompt, an error message), detect PHI-shaped values and return a redacted version.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Raw text that may contain PHI

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does state the core behavior—detecting PHI-shaped values and returning a redacted version—but it does not mention whether detection is heuristic, what kinds of PHI patterns are covered, or any limitations. It is adequate for a simple transformation tool but not richly transparent.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no waste. It states the input context, the detection behavior, and the output in a compact structure that is easy to parse.

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

Completeness4/5

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

For a single-parameter tool with no output schema, the description covers the essential context: what input is expected and what output is returned. It could add more detail about the redaction format or heuristic nature of PHI detection, but the definition is largely sufficient for correct invocation.

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?

The schema already documents the text parameter at 100% coverage, so the baseline is 3. The description adds value by giving concrete examples of acceptable input types—log line, prompt, error message—which helps the agent understand the intended scope beyond the schema's generic 'Raw text that may contain PHI'.

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

Purpose4/5

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

The description clearly states a specific action ('detect PHI-shaped values and return a redacted version') applied to a defined resource ('raw text snippet'). It distinguishes itself from the sibling scan_code by focusing on text snippets like logs and prompts rather than code, though it does not explicitly name the alternative.

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

Usage Guidelines3/5

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

The description provides implied usage context: use this tool for raw text that may contain PHI-shaped values. However, it does not explicitly state when not to use it or how it compares to scan_code, leaving the routing decision partially to inference.

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

scan_codeA

Scan a local directory of source files for sensitive identifiers (patient, diagnosis, dob, ssn, mrn) flowing into risky sinks (LLM calls, logging, analytics) before they ship.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute path to the directory or repo to scan

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly conveys a read-oriented scan behavior and the matching criteria, but it does not state whether the tool returns findings, modifies files, or has other side effects, leaving some behavior implicit.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the action and then narrows the scope with specific identifiers and sinks. Every clause contributes information, with no filler or redundancy.

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

Completeness4/5

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 and no annotations, the description provides enough context for an agent to invoke it correctly: what to scan, what to look for, and when to run it. It could be improved by stating the result format or confirming it is non-mutating, but nothing essential is missing.

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

Parameters3/5

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

Schema coverage is 100%, and the only parameter 'path' is already described as an absolute path to a directory or repo. The description adds contextual flavor like 'local' and 'source files,' but it does not add 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.

Purpose4/5

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

The description uses a specific verb ('Scan') and resource ('local directory of source files'), and precisely defines what it detects: sensitive identifiers flowing into risky sinks. It is clearly distinguishable from the sibling redact_suggest by its purpose, though it never explicitly names or contrasts that sibling.

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

Usage Guidelines4/5

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

The description provides clear temporal and contextual guidance: run this before code ships, on local source directories, to catch sensitive data going into LLM calls, logging, or analytics. It does not explicitly name alternatives or exclusions, so it falls 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesv0.1.3Aug 29, 2026
- First observedredact_suggest
- First observedscan_code

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

redact_suggest operates on raw text for de-identification, while scan_code analyzes source code for risksy data flows. Their inputs, outputs, and use cases are completely distinct, so an agent should have no trouble separating them.

Naming Consistency3/5

scan_code follows a clear verb_noun pattern, but redact_suggest is an awkward combination that is not clearly verb+object. With only two tools, the inconsistency is noticeable though both names remain understandable.

Tool Count3/5

Two tools feels thin for a PHI protection server, though the pair does cover two meaningful workflows: runtime text redaction and pre-ship code scanning. It is a borderline scope rather than an obviously excessive or trivial one.

Completeness3/5

The set covers redaction suggestion and source scanning, but leavoves out supporting operations like pattern configuration, allowlisting, detailed finding management, or remediation/apply flows. These are notal gaps that agents may need to work around.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

healthguard A
io.tooloracle
HealthGuard - 12-tool health/medical AI safety MCP: PII redaction, HIPAA, GDPR Art.9.
Security Legal & Compliance
122
Custosa ToolsOAuth
com.custosa
Scans schema metadata to classify PHI, score HIPAA readiness, and generate compliant migrations.
Databases Security Biology & Medicine
2
HIPAA Agent A
io.github.xbt786
HIPAA compliance AI agent — scan, grade, SRA, and generate compliance docs.
Legal & Compliance Health & Wellness Autonomous Agents
2
secret-scanner A
tools.knurl
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Security Penetration Testing
12

Related MCP Servers

ai-security-gateway-mcp
Security AI & Machine Learning
dceptev-byte
A
license
A
quality
D
maintenance
Scans prompts for PII and masks or redacts sensitive data locally before sending to an LLM, supporting multiple anonymization modes.
Updated 5 months ago (2026-03-23 12:40 UTC)
1
MIT
phi-guard-mcp
Biology & Medicine Security
charlesree826
A
license
A
quality
A
maintenance
MCP server and CLI for detecting, redacting, and auditing PHI in medical text before it reaches AI agents.
Updated 2 months ago (2026-06-29 10:49 UTC)
4
MIT
VibeGuard MCP Server
Penetration Testing Code Analysis
yagyeshVyas
A
license
Not graded
quality
A
maintenance
Enables AI coding tools to scan projects for security vulnerabilities, hardcoded secrets, injection flaws, and privacy violations with 699 rules and 76 MCP tools, all running locally with zero telemetry.
Updated 8 days ago (2026-08-29 10:13 UTC)
22
6
MIT
netallion-mcp-lite
netallion
A
license
Not graded
quality
A
maintenance
Scans text and files for common secrets (AWS, GitHub, etc.) and redacts them to prevent credential leakage in AI-assisted development. Runs entirely locally with no telemetry.
Updated 2 months ago (2026-07-19 23:19 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Abidit/phi-guard-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

phi-guard-mcp

Why

Tools

redact_suggest

scan_code

Tested against

What this is NOT

Setup

Claude Code

Verifying

License

Mcp Server Approved

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

ai-security-gateway-mcp

phi-guard-mcp

VibeGuard MCP Server

netallion-mcp-lite

Latest Blog Posts

MCP directory API

`redact_suggest`

`scan_code`