What can you do with this server?

It is a secure MCP server for running read-only PostgreSQL queries with automatic PII masking, plus tools to restore masked values and manage PII detection. * Run read-only SELECT queries via run_secure_query; results are automatically masked for names, emails, phones, and IDs. * Restore original PII values from masked text using unmask_text for placeholders cached during the session. * Add custom names to the detection roster with add_to_roster to improve local name-matching. * Supports concurrent clients over SSE with API-key authentication, and local/stdio execution via npx. * Provides a /stats endpoint for telemetry on connections, unique clients, and query execution. * Uses in-memory, TTL-based pseudonymization so masked PII leaves no persistent disk footprint.

Which integrations are available for this server?

Provides secure, read-only PostgreSQL query execution with automatic PII masking, pseudonymization, and restoration capabilities for AI agents.

How do I use pc2e-pii-shield?

1. Click on "Deploy 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., "@pc2e-pii-shield Get the last 10 orders with customer names but replace PII with placeholders" 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.

de en es ja ko ru zh

pc2e-pii-shield

by thegeekybeng

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

pc2e-pii-shield

M8ven Verified

A secure, production-grade Model Context Protocol (MCP) server providing read-only PostgreSQL query execution with automatic, client-side, and edge Personally Identifiable Information (PII) masking. It allows LLM agents (e.g., Cursor, Cline, Claude Code) to execute SQL queries on databases while ensuring strict compliance with GDPR, PDPA, and data privacy principles.

Designed and engineered as a reusable security middleware product, this server intercepts database query results to prevent sensitive data egress.

Technical Architecture

flowchart TD
    Client["AI Agent / Client (Cursor/Cline)"]
    Proxy["Nginx Reverse Proxy"]
    App["pc2e-pii-shield (Express)"]
    DB["Postgres Database (Tailscale-Only)"]

    Client ==>|HTTPS / SSE Request| Proxy
    Proxy ==>|x-api-key Authentication| App
    App ==>|Regex Read-Only Validation| DB
    DB ==>|Raw SQL Results| App
    App ==>|PII Tokenization & Masking| Proxy
    Proxy ==>|Sanitized Event Stream| Client

Core Components

Auto-Masking Interceptor (masking.ts): Dynamically scans SQL result sets. It utilizes a hybrid approach: column schema matching (e.g., fields containing name, email, phone) combined with regex-based content scanning to detect and mask sensitive identifiers before data leaves the server.
Pseudonymization Cache (cache.ts): An in-memory, TTL-backed cache (default: 30 minutes) that maps raw values to temporary placeholders (e.g., __PERSON_A__, __EMAIL_1__). This allows bi-directional restoration while preventing unbounded memory consumption.
AST-Level Mutation Guard (db.ts): A strict regex validator that intercepts raw SQL inputs. It blocks any non-SELECT commands and rejects queries containing forbidden keywords such as DROP, ALTER, DELETE, TRUNCATE, CREATE, or GRANT, ensuring a strict read-only boundary at the application layer.
Concurrent Session Manager (index.ts): Unlike basic single-connection templates, this server maintains an active map of SSEServerTransport instances keyed by connection sessionId, allowing multiple remote developers or agents to connect and stream concurrently without state collisions.
Telemetry & Metrics Endpoint (/stats): Exposes connection counts, unique client IP tracking, and aggregate query execution statistics to monitor installation and active usage in real-time.

Related MCP server: PostgreSQL MCP Server

Security Model & Threat Mitigation

Zero-Trust Database Connectivity: Designed to prevent credential exposure. The database runs on an isolated Tailscale-only network interface (e.g., 100.92.174.76), ensuring the database port is never exposed to the public internet.
Encrypted Transport & API Key Security: The server is fronted by Nginx over HTTPS (port 443) using wildcard SSL certificates, enforcing a secure API key authentication gate (x-api-key) before forwarding requests.
In-Memory Lifecycle: Pseudonymization mappings are stored in memory with strict TTLs, leaving no persistent disk footprints of the masked PII.

Installation & Deployment

1. Prerequisite Environment Setup

Copy the environment template:

cp .env.example .env

Configure your database credentials and generate a secure API key inside .env.

2. Native Build

Ensure Node.js (v18+) is installed:

npm install
npm run build
npm start

3. Containerized Deployment

Deploy using Docker Compose:

docker compose up -d --build

This maps host port 3088 to the container's internal port 3000, running the SSE server automatically.

4. Direct Execution (NPX)

You can run the server instantly over Stdio transport without downloading the code manually:

npx -y mcp-pii-shield --db-uri "postgresql://username:password@localhost:5432/your_database"

Or run the server over SSE transport:

npx -y mcp-pii-shield --sse --port 3000 --db-uri "postgresql://username:password@localhost:5432/your_database" --api-key "your_secret_key"

Client Integration

A. Local Client Integration (via NPX over Stdio)

Configure your local AI client to launch the server directly using npx.

Claude Desktop (`config.json`)

Add the following block to your ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "pc2e-pii-shield": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-pii-shield",
        "--db-uri",
        "postgresql://username:password@localhost:5432/your_database"
      ]
    }
  }
}

Cursor (Settings → Features → MCP)

Click + Add New MCP Server.
Set Name to pc2e-pii-shield.
Set Type to command.

Set Command to:

npx -y mcp-pii-shield --db-uri "postgresql://username:password@localhost:5432/your_database"

VS Code (Cline / Roo Code)

Add the following to your client settings JSON:

{
  "mcpServers": {
    "pc2e-pii-shield": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-pii-shield",
        "--db-uri",
        "postgresql://username:password@localhost:5432/your_database"
      ]
    }
  }
}

B. Remote Client Integration (via HTTPS over SSE)

If you are connecting to a hosted server (e.g., your public NAS instance), connect via the SSE transport URL.

VS Code (Cline / Roo Code)

{
  "mcpServers": {
    "pc2e-pii-shield": {
      "sseUrl": "https://pii-shield.thegeekybeng.com/sse?api_key=your_api_key_here"
    }
  }
}

Cursor

Click + Add New MCP Server.
Set Name to pc2e-pii-shield.
Set Type to SSE.

Set URL to:

https://pii-shield.thegeekybeng.com/sse?api_key=your_api_key_here

Project Context & Technical Lead

This project was architected, built, and open-sourced by Andrew Yeo.

About the Lead Architect

Andrew is a Senior Systems Architect and AI Engineer based in Singapore, offering:

25 years of professional experience in APAC, managing program delivery, client onboarding, and technical vendor management.
16+ years of systems architecture and technology leadership, designing and deploying robust enterprise infrastructures and microservice platforms.
2+ years of dedicated hands-on AI/ML engineering, specializing in AI safety, LLM metrics, and secure agentic workflows.

Verified Proof-of-Work

Secure Civic Platforms: Architected and deployed MPS-Connect (a civic constituency casework platform) and Case-Writer-Intelligence (CWI), integrating a 3-stage causality engine with 7 human-in-the-loop approval gates, reducing document triage time by 40%.
AI Metrology & Testing: Designed the Portable Continuous Context Engine (PC2E), running a systematic, empirical evaluation of 50,000 cases across six LLM providers to benchmark model alignment and compliance.
Technical Focus: Expert in CI/CD & DevSecOps (GitHub Actions, Docker), containerized deployments, zero-trust network topologies, and local/edge SLM orchestrations.

Available Tools

3 tools

add_to_rosterA

ParametersJSON Schema

Name	Required	Description	Default
`names`	Yes	An array of names to be dynamically added to the scanner roster.

TDQS

A3.6/5.0

Behavior3/5

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

Annotations are not provided, so the description carries the burden, but it is minimal. It clarifies the scope (local name-matching detection) but does not disclose behavioral traits such as whether the roster is persistent, how additions affect existing entries, or any potential side effects (e.g., deduplication). It goes beyond a simple 'Add' but lacks substantial behavioral context.

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, concise sentence that packs essential information: action, target, and purpose. It is front-loaded with the verb. No filler or redundant content. Five is appropriate for its brevity and efficiency.

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

Completeness3/5

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

The tool is simple with one parameter and no output schema. The description covers the purpose and target, but lacks details about behavior (e.g., duplicates, confirmation) and does not mention return values. Given the low complexity, this is acceptable but not fully complete; a 3 is appropriate.

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 description coverage is 100% (the parameter 'names' is documented as 'An array of names to be dynamically added to the scanner roster'). The description adds value by clarifying that the names are 'new' and for 'local name-matching detection', which enhances the schema's meaning. With full coverage, baseline is 3; the added specificity justifies a 4.

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 'Register new names to the active regex scan roster for local name-matching detection' clearly states the action (register names), the resource (active regex scan roster), and the purpose (local name-matching detection). It distinguishes from siblings (unmask_text, run_secure_query) by specifying the roster for name-matching, which is specific enough.

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 implies usage context (for local name-matching detection) but does not explicitly specify when to use this tool versus alternatives, nor any exclusions (e.g., when to prefer unmask_text). Sibling tools exist but are not referenced or contrasted. Adequate but lacks explicit guidance.

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

run_secure_queryA

Execute a read-only SELECT database query. All PII values (names, emails, phones, NRIC/IDs) in the results will be automatically masked before being returned.

ParametersJSON Schema

Name	Required	Description	Default
`sql_query`	Yes	The read-only SQL SELECT query to run (e.g. SELECT name, email FROM contacts LIMIT 5)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden, and it does so well by disclosing: (1) the operation is read-only, and (2) all PII values in results will be automatically masked. This gives the agent critical behavioral expectations (e.g., don't expect unmasked PII in results). It does not cover edge cases like error handling or large result pagination, but for the information provided, this is a strong disclosure.

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?

Two sentences (33 words) with a clear action-first structure. Front-loads the primary purpose ('Execute a read-only SELECT database query') and follows with the key behavioral differentiator (PII masking). Every word contributes meaning; no filler.

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 simple 1-parameter tool with no output schema, the description covers all essential aspects: the operation, the constraint on input, and a key output transformation (masking). Additional details like error messages for invalid queries or rate limiting would be nice but are not critical for this complexity, and the behavioral notes alone elevate it above the norm.

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 description coverage is 100%, so the baseline is 3. The description adds value by qualifying the query as 'read-only' and emphasizing the PII masking behavior, which affects result processing semantics beyond what the schema example shows. It could have gone further by specifying what happens with non-SELECT input (error vs. rejection).

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 description clearly states the action ('Execute a read-only SELECT database query') with a specific verb and resource, and the PII masking note explains what makes it 'secure.' This effectively differentiates it from sibling tools (unmask_text, add_to__roster) by making clear this is the querying tool that returns masked data.

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 implies when to use this tool (read-only data retrieval) but does not explicitly state alternatives or exclusions (e.g., 'for write operations use X'). The sibling tools could offer more context, but no explicit comparison is provided. The read-only and SELECT constraints give some usage guardrails.

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

unmask_textA

Restore the original raw PII values in a text payload by replacing placeholders (e.g. PERSON_A, EMAIL_1) with their original values cached during this session.

ParametersJSON Schema

Name	Required	Description	Default
`masked_text`	Yes	The text containing placeholders to be restored.

TDQS

A4.2/5.0

Behavior3/5

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

There are no annotations, so the description must convey behavior. It mentions the session-cached values but does not disclose what happens if the cache is missing, whether the operation is reversible, or any side effects (e.g., does it mutate input or return a new string?). It provides some context but lacks critical behavioral details for a tool with no annotations.

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, efficient sentence that front-loads the core action and provides examples. It contains no redundant or tangential information, making it optimally concise.

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 tool with one parameter and no output schema, the description covers the main mechanism but omits the return value and potential error conditions (e.g., missing cache entries). While the session dependency is mentioned, a mention of expected output or failure handling would enhance completeness. Still, it is adequate for a simple tool.

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 provides a basic description of 'masked_text.' The tool description adds value by giving concrete examples of placeholder formats and explaining that they are replaced with original values. This goes beyond the schema's simple definition, enriching parameter understanding.

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 description clearly states the tool's purpose: restoring original PII values by replacing placeholders like __PERSON_A__ and __EMAIL_1__ with cached values. It uses a specific verb and resource, making it unmistakable. Although siblings are unrelated, the purpose is distinct and well-defined.

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?

It implies usage context by mentioning 'cached during this session,' which tells the agent when the tool is applicable (after a prior masking operation). It does not explicitly list alternatives or exclusions, but given the unrelated siblings, this is not a significant gap. The context is clear enough for selecting this tool.

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 updatesv1.0.0Aug 21, 2026
- First observedadd_to_roster
- First observedrun_secure_query
- First observedunmask_text

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-08-21 00:10 across 3 tools

Disambiguation5/5

Each tool addresses a distinct concern: one unmask text, one manage the name roster, and one execute queries with automatic masking. There is no overlap that would cause an agent to misselect.

Naming Consistency4/5

Most tools follow a verb_noun pattern (unmask_text, run_secure_query), but add_to_roster breaks the pattern with an intervening preposition. This is a minor deviation and the intent remains clear.

Tool Count4/5

Three tools is a reasonable, focused set for a PII-shielding server. It is slightly lean but each tool serves a clear purpose without unnecessary bloat.

Completeness3/5

The core masking lifecycle is covered—query masking, unmasking, and roster management—but obvious gaps exist: no tool for masking non-query text, no roster removal or listing, and no way to manage the cached placeholders beyond unmasking. These gaps could force workarounds.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

DB Query Guard MCP
com.clauxel.dbqueryguard
Paid remote MCP for governed database query review, SQL simulation, approvals, and audits.
Databases Security
2
PGAuditor
com.mcpgatepro
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Databases Monitoring Observability
1
Draxlr AOAuth
com.draxlr.api
Draxlr's remote MCP server connects AI assistants to your SQL databases and dashboards. Explore schemas, run read-only queries, manage saved queries and dashboards, and export results, all with row-level security so each user sees only their own data.
Data Visualization Databases Search
151
dataOAuth
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2

Related MCP Servers

PostgreSQL Read-Only MCP
Databases Security
currentspace
F
license
Not graded
quality
D
maintenance
A secure MCP server that enables querying PostgreSQL databases through an SSH tunnel with enforced read-only access, connection pooling, and comprehensive data exploration tools.
Updated a year ago (2025-07-08 01:21 UTC)
-
PostgreSQL MCP Server
Databases Developer Tools
datdeboer
A
license
Not graded
quality
D
maintenance
A production-ready MCP server that enables safe, read-only SQL SELECT queries against PostgreSQL databases with built-in security validation. It features connection pooling, automatic row limits, and structured logging to ensure secure and reliable database interactions.
Updated 7 months ago (2026-02-16 17:44 UTC)
33 npm
ISC
mcp-postgres
Databases Developer Tools
gbfeliped
A
license
Not graded
quality
D
maintenance
Read-only PostgreSQL MCP server that enables running SELECT queries, listing tables and schemas, and describing columns, with built-in protection against writes and malicious SQL attacks.
Updated 3 months ago (2026-06-18 14:32 UTC)
442 npm
MIT
postgres-mcp-readonly
Databases Developer Tools
mahin1995
A
license
A
quality
D
maintenance
A secure, read-only PostgreSQL MCP server that provides safe database introspection and querying capabilities.
Updated 4 months ago (2026-05-04 16:20 UTC)
14
10 npm
MIT

pc2e-pii-shield

Technical Architecture

Core Components

Security Model & Threat Mitigation

Installation & Deployment

1. Prerequisite Environment Setup

2. Native Build

3. Containerized Deployment

4. Direct Execution (NPX)

Client Integration

A. Local Client Integration (via NPX over Stdio)

Claude Desktop (config.json)

Cursor (Settings → Features → MCP)

VS Code (Cline / Roo Code)

B. Remote Client Integration (via HTTPS over SSE)

VS Code (Cline / Roo Code)

Cursor

Project Context & Technical Lead

About the Lead Architect

Verified Proof-of-Work

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Claude Desktop (`config.json`)