What can you do with this server?

The sensitive-info-mcp server detects and masks sensitive information in text and files using regular expressions, validation algorithms, and optional AI-based semantic detection. It supports 14+ types of sensitive data (phone numbers, ID cards, bank cards, emails, API keys, JWTs, private keys, AWS keys, GitHub tokens, passwords, etc.). * Scan text (scan_text): Detect sensitive data in a string, returning JSON results. * Mask text (mask_text): Detect and redact sensitive info using configurable strategies: mask, replace, hash, keep_format, or redact. * Generate report (scan_report): Produce a Markdown-formatted report of all findings in a given text. * Scan file (scan_file): Analyze a file for sensitive information and return JSON-formatted results. * Mask file (mask_file): De-identify sensitive content in a file, saving to a new path or overwriting in place. * List rules (list_rules): Retrieve all built-in detection rules currently configured. * AI semantic detection: Optionally enable LLM-based detection (via OPENAI_API_KEY) to catch obfuscated or context-dependent sensitive info. * Batch scan & unified reporting: Prescreen code/config snippets and combine rule-based and LLM-based findings into a single report. * Integration options: Python SDK, CLI, and GitHub Action support.

Which integrations are available for this server?

Leverages OpenAI's LLM for AI-enhanced semantic detection of sensitive information, identifying context-based privacy risks.

How do I use sensitive-info-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., "@sensitive-info-mcp mask my phone number 13812345678" 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.

sensitive-info-mcp

by hawklithm

Overview Schema Related Servers Score Discussions

Python

Local

🔒 Sensitive Info MCP

规则驱动的敏感信息检测与数据脱敏 MCP 服务器 + LLM Skill 协同

一个 Model Context Protocol (MCP) 服务器，用于检测和脱敏文本/文件/代码中的敏感信息。支持 14+ 类敏感信息识别，结合正则规则 + 校验算法做基础检测，并提供掩码、替换、哈希等多种脱敏策略。LLM 语义检测通过 Skill 编排 AI 助手完成（MCP 不内置 LLM 调用）。

✨ 特性

全面检测：手机号、身份证、银行卡、邮箱、API Key、JWT、私钥、AWS Key、GitHub Token 等 14+ 类
智能校验：身份证校验位算法、银行卡 Luhn 校验，降低误报
MCP/Skill 分工：基础检测在 MCP（快、确定性），LLM 语义检测在 Skill（识别变形/拆分/上下文隐私），职责清晰
灵活脱敏：5 种策略（掩码/替换/哈希/保留格式/删除），支持按类型自定义
中文友好：所有正则使用 lookaround 断言，完美兼容中文环境
多形态使用：MCP Server（Claude/Cursor/CodeBuddy）、CLI 命令行、Python SDK、GitHub Action

Related MCP server: MCP Presidio

📦 安装

pip install -e .

🚀 快速开始

1. CLI 命令行

# 检测敏感信息
sensitive-info-mcp "我的手机号是13812345678"

# 脱敏输出
sensitive-info-mcp "我的手机号是13812345678" --mask

# 生成 Markdown 报告
sensitive-info-mcp "身份证：110101199003071233" --report

# 扫描文件
sensitive-info-mcp --file ./config.yaml --mask

2. MCP Server（Claude Desktop / Cursor / CodeBuddy）

在客户端配置文件中添加：

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "sensitive-info": {
      "command": "sensitive-info-mcp",
      "args": []
    }
  }
}

Cursor / CodeBuddy (.codebuddy/mcp.json 或对应配置):

{
  "mcpServers": {
    "sensitive-info": {
      "command": "python3",
      "args": ["-m", "sensitive_info_mcp.server"]
    }
  }
}

配置后，AI 助手即可调用以下工具：

工具	功能
`scan_text`	检测文本中的敏感信息（基础规则）
`mask_text`	检测并脱敏文本
`scan_report`	生成单文本 Markdown 扫描报告
`scan_file`	扫描文件
`mask_file`	脱敏文件并保存
`list_rules`	列出所有检测规则
`scan_snippets`	批量对多个代码/配置片段做基础初筛（配合 Skill）
`build_report`	汇总 rule + llm 来源检测结果生成统一报告（配合 Skill）

3. Python SDK

from sensitive_info_mcp.scanner import Scanner

scanner = Scanner()

# 检测
findings = scanner.detect("联系我：13812345678 或 test@qq.com")
for f in findings:
    print(f"[{f.type.value}] {f.value} → 风险:{f.risk_level.value}")

# 脱敏
masked, findings = scanner.mask("手机号13812345678")
print(masked)  # 手机号138****5678

# 完整报告
report = scanner.report("身份证：110101199003071233")
print(report.to_markdown())

🔧 配置

脱敏策略

策略	说明	示例
`auto`（默认）	使用各类型默认策略	手机号→掩码，API Key→替换
`mask`	部分掩码	`138****5678`
`replace`	完全替换	`[REDACTED]`
`hash`	SHA256 哈希	`hash:a1b2c3...`
`keep_format`	保留格式	`z******@example.com`
`redact`	完全删除	`[REDACTED]`

from sensitive_info_mcp.types import MaskConfig, MaskStrategy
from sensitive_info_mcp.scanner import Scanner

# 全局强制使用替换策略
scanner = Scanner(mask_config=MaskConfig(strategy=MaskStrategy.REPLACE))

# 按类型自定义
scanner = Scanner(mask_config=MaskConfig(
    type_overrides={
        "phone": {"strategy": "hash"},
        "email": {"strategy": "keep_format"},
    }
))

🤝 结合 Skill 做 LLM 语义检测

本 MCP 仅做基础检测（正则 + 校验算法），不内置 LLM 调用。LLM 语义检测（识别变形/拆分敏感信息、非标准命名的硬编码凭据、内网信息、上下文隐私等）通过 Skill 编排 AI 助手完成 —— 因为 AI 助手本身就在执行 LLM，无需 MCP 再调外部 API。

工作流

代码 / 配置片段
     │
     ├─ codegraph 取常量/变量定义 + Glob/Read 取配置文件
     ▼
┌───────────────────────┐
│ MCP scan_snippets       │ ── rule 初筛 ──┐
│ (正则 + 校验算法)       │                │
└───────────────────────┘                │
     │ 初筛未命中片段                      │
     ▼                                    │
┌───────────────────────┐                │
│ AI 助手 LLM 二次筛选    │ ── llm findings│
│ (Skill 识别规则)        │ ──────────────►│
└───────────────────────┘                │
     ▼                                    ▼
┌───────────────────────┐
│ MCP build_report        │ → 统一 Markdown 报告（区分 rule/llm 来源）
└───────────────────────┘

安装 Skill

将 skills/sensitive-info-scan/SKILL.md 复制到 CodeBuddy / Cursor 的 skills 目录：

# CodeBuddy
mkdir -p ~/.codebuddy/skills/sensitive-info-scan
cp skills/sensitive-info-scan/SKILL.md ~/.codebuddy/skills/sensitive-info-scan/SKILL.md

# 或 Cursor / Claude Code 对应 skills 目录

重启会话后，对用户说"扫描代码中的敏感信息"，AI 助手会自动按 Skill 工作流执行：codegraph 取片段 → MCP 初筛 → LLM 二筛 → build_report 生成报告。

Skill 也可在无 codegraph 环境下工作（回退为 Grep 赋值行收集片段），详见 SKILL.md。

📋 支持的敏感信息类型

类型	标识	风险等级	校验
手机号	`phone`	高	-
身份证号	`id_card`	严重	✅ 校验位
银行卡号	`bank_card`	严重	✅ Luhn
邮箱	`email`	中	-
API Key	`api_key`	高	-
AWS Key	`aws_key`	严重	-
GitHub Token	`github_token`	严重	-
JWT	`jwt`	严重	-
私钥	`private_key`	严重	-
密码	`password`	高	-
URL 凭据	`url_with_cred`	高	-
IP 地址	`ip_address`	低	-
社会保障号	`ssn`	高	-
LLM 检测	`llm_detected`	中-严重	- (Skill 二次筛选产生)

添加自定义规则

from sensitive_info_mcp.detectors.rules import Rule, RuleDetector
from sensitive_info_mcp.types import SensitiveType, RiskLevel
import re

custom = Rule(
    type=SensitiveType.CUSTOM,
    pattern=re.compile(r"(?<!\d)EMP\d{6}(?!\d)"),  # 员工号 EMP123456
    risk_level=RiskLevel.MEDIUM,
    confidence=0.9,
    description="内部员工编号",
)

scanner = Scanner(extra_rules=[custom])

🏗️ 架构

输入文本 / 文件 / 代码片段
   │
   ▼
┌───────────────────┐
│  规则检测器         │  正则 + 校验算法（身份证校验位 / 银行卡 Luhn）
│  (RuleDetector)    │  → 14+ 类已知格式敏感信息
└────────┬──────────┘
         │
         ▼
┌───────────────────┐
│  脱敏处理器         │  掩码 / 替换 / 哈希 / 保留格式 / 删除
│  (Masker)          │
└────────┬──────────┘
         ▼
   脱敏文本 + 检测报告

┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
LLM 语义检测（在 Skill 层，不在 MCP 内）：
  codegraph 取片段 → scan_snippets 初筛 → AI 助手 LLM 二筛 → build_report

📁 项目结构

sensitive-info-mcp/
├── src/sensitive_info_mcp/
│   ├── server.py          # MCP Server + CLI 入口（8 个工具）
│   ├── scanner.py         # 扫描器（基础规则检测 + 脱敏）
│   ├── types.py           # 类型定义
│   ├── detectors/
│   │   ├── base.py        # 检测器基类
│   │   └── rules.py       # 规则检测引擎（14+ 类）
│   └── maskers/
│       └── processor.py   # 脱敏处理器
├── skills/
│   └── sensitive-info-scan/
│       └── SKILL.md       # LLM 语义检测 Skill（codegraph + MCP + AI 助手协同）
├── action.yml             # GitHub Action
├── examples/              # 使用示例
├── tests/                 # 测试用例
└── pyproject.toml

🧪 测试

python tests/test_core.py

📄 License

MIT

Available Tools

6 tools

list_rulesA

列出当前所有内置检测规则

Returns: JSON 格式的规则列表

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are present, so the description must carry the full burden. It discloses that the return is in JSON format, but does not explicitly state that the operation is read-only or safe, nor does it mention any permissions or side effects. This is a minimal disclosure for a list operation.

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?

The description is concise, with two sentences covering the action and return format. It is front-loaded with the verb. However, it could be slightly more structured with bullet points or clearer language, so not a perfect 5.

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?

Given the tool has an output schema and zero parameters, the description sufficiently states it returns a JSON list of built-in detection rules. This is complete for a simple listing tool, though it could specify if there are any filters or pagination (unlikely given no params).

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?

There are no parameters, and the input schema has 100% coverage trivially. The description adds meaning by specifying that the output is a JSON list of rules, which is beyond the empty schema. Baseline for zero parameters is 4.

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 lists all built-in detection rules, with the verb '列出' (list) and resource '内置检测规则' (built-in detection rules). This distinguishes it from sibling tools that scan or mask, providing clear purpose.

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?

No explicit when-to-use or when-not-to-use guidance is provided. However, given the tool's simplicity and lack of parameters, the context implies it is used to obtain the rule list before engaging other tools, but no alternatives or exclusions are mentioned.

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

mask_fileB

脱敏文件内容并保存

Args: file_path: 输入文件路径 output_path: 输出文件路径（与 inplace 互斥） mask_strategy: 脱敏策略 enable_ai: 是否启用 AI 检测 inplace: 是否原地覆盖（慎用）

Returns: 操作结果 JSON

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes
`output_path`	No
`mask_strategy`	No
`enable_ai`	No
`inplace`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior3/5

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

The description notes that inplace is '慎用' (use with caution), hinting at destructive behavior, but lacks details on permissions, side effects, or behavior when output_path is null. With no annotations, more disclosure is expected.

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?

The description is a structured docstring with concise bullet points, no wasted words. It is appropriately sized for the tool's complexity.

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 description covers the main function and lists parameters, but omits details on mask strategy options, AI detection behavior, and handling of null output_path. An output schema exists but is not used to reduce burden.

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

Parameters2/5

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

Schema description coverage is 0%, requiring the description to compensate. It only names parameters with a caution note for inplace, but does not explain mask_strategy values, enable_ai behavior, or path formats.

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 'desensitize file content and save', specifying the verb and resource. It distinguishes from sibling mask_text by focusing on file operations, but does not explicitly differentiate.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like mask_text. No exclusions or prerequisites mentioned.

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

mask_textB

检测并脱敏文本，返回脱敏后的文本

Args: text: 待脱敏文本 mask_strategy: 脱敏策略 mask|replace|hash|keep_format|redact enable_ai: 是否启用 AI 语义检测

Returns: 脱敏后的文本

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`mask_strategy`	No
`enable_ai`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions detection and desensitization but does not explain side effects, permission requirements, rate limits, or the exact impact of different mask_strategy options.

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?

The description is concise, with the core purpose stated first. The Args section is well-structured, though it uses a code-style format that could be streamlined. No unnecessary information is present.

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 has three parameters and sibling tools in a similar domain. The description covers basic functionality but lacks details on output structure (despite an output schema existing) and does not fully explain the behavior of each mask strategy. It is adequate but not thorough.

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?

The input schema has 0% description coverage, so the description must compensate. It lists the three parameters with brief explanations (e.g., mask_strategy options as 'mask|replace|hash|keep_format|redact' and enable_ai as 'enable AI semantic detection'), but does not elaborate on the meaning or effect of each strategy, leaving gaps.

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 action: 'detect and desensitize text, return desensitized text.' It specifies the resource (text) and verb (mask), and distinguishes from sibling tools like mask_file (which works on files) and scan_text (which scans but does not mask).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as scan_text or mask_file. It does not mention prerequisites, limitations, or recommended scenarios.

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

scan_fileB

扫描文件中的敏感信息

Args: file_path: 文件路径 enable_ai: 是否启用 AI 检测 mask_strategy: 脱敏策略

Returns: JSON 格式的检测结果

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes
`enable_ai`	No
`mask_strategy`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only states that the tool returns JSON detection results, but does not disclose whether it is read-only, destructive, or requires specific permissions. No side effects or behavioral traits are mentioned.

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?

The description is concise with a single purpose line and clearly separated Args/Returns sections. Every sentence is functional, though the main description could be more front-loaded. No redundant content.

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

Completeness2/5

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

Given the presence of an output schema (implied but not shown), the description should explain what the detection results contain, the effect of enable_ai, and possible mask_strategy values. It lacks this context, making it incomplete for an AI agent to fully understand the tool's behavior.

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?

With 0% schema description coverage, the description adds meaning by naming each parameter and giving brief Chinese explanations: '文件路径' for file_path, '是否启用 AI 检测' for enable_ai (adding AI context), and '脱敏策略' for mask_strategy. This goes beyond the schema's type/default, but still lacks detail on expected values or behavior.

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 verb (scan) and resource (files) for sensitive information. It distinguishes from siblings like scan_text and scan_report by specifying files. The purpose is specific and unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as scan_text, mask_file, or list_rules. The description does not mention prerequisites, context, or exclusions.

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

scan_reportB

生成完整的 Markdown 扫描报告

Args: text: 待扫描文本 enable_ai: 是否启用 AI 检测 mask_strategy: 脱敏策略

Returns: Markdown 格式的扫描报告

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`enable_ai`	No
`mask_strategy`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, has side effects, requires authentication, or any rate limits. It only says it generates a report, which implies a nondestructive operation, but this is not explicit. Critical behavioral context is missing.

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 highly concise: a single main sentence followed by a structured Args/Returns list. Every element contributes to understanding the tool. No redundant or unnecessary words. It is front-loaded and well-organized.

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 description covers the basic purpose and parameters, and an output schema exists to document return values. However, it lacks clarity on how this tool differs from siblings like scan_text, and it omits details about the mask_strategy parameter's possible values. For a tool with moderate complexity, it is adequate but not fully complete.

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?

The description adds moderate meaning to the parameters: 'text' is described as '待扫描文本' (text to be scanned), 'enable_ai' as '是否启用 AI 检测' (whether to enable AI detection), and 'mask_strategy' as '脱敏策略' (masking strategy). This goes beyond the schema which only provides names and types. However, it does not specify allowed values for mask_strategy or the effect of enable_ai, leaving gaps.

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 the tool generates a complete Markdown scan report, which is a specific verb-resource combination. However, it does not explicitly differentiate from sibling tools like scan_file or scan_text, which likely produce different outputs (e.g., structured data). The purpose is clear but not distinguished from alternatives.

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

Usage Guidelines2/5

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 siblings such as scan_file, scan_text, or mask_text. There is no mention of prerequisites, context, or when not to use this tool. The description only states what it does, leaving the agent to infer usage independently.

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

scan_textA

检测文本中的敏感信息

Args: text: 待检测文本 enable_ai: 是否启用 AI 语义检测（需配置 OPENAI_API_KEY 环境变量） mask_strategy: 脱敏策略，可选 mask|replace|hash|keep_format|redact

Returns: JSON 格式的检测结果列表

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`enable_ai`	No
`mask_strategy`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Lacks annotations, so description must carry burden. It mentions the AI detection requirement and mask strategy options, but does not disclose read-only nature, rate limits, or permissions needed.

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?

Description is concise with clear section headers for args and returns. No wasted sentences, though slightly verbose for a short text.

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?

With output schema present (not shown) and parameters fully described, the description covers essential info. However, it omits context like prerequisites (API key) and relationship to siblings.

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

Parameters5/5

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

Input schema coverage is 0%, so description fully compensates. It explains each parameter: 'text' as the text to scan, 'enable_ai' with environment requirement, and 'mask_strategy' with explicit enum values (mask|replace|hash|keep_format|redact).

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 the tool's purpose: detecting sensitive information in text. However, it does not differentiate from sibling tools like scan_file or mask_text, which could cause confusion.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. With siblings like scan_file and mask_text available, the description should mention scenarios 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. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jun 20, 2026
- First observedlist_rules
- First observedmask_file
- First observedmask_text
- First observedscan_file
- First observedscan_report
- First observedscan_text

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing rules, masking files/text, scanning files/text, and generating reports. The only potential overlap (scan_text vs. scan_report) is resolved by different return formats (JSON vs. Markdown).

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_rules, mask_file, scan_text). No mixing of conventions or irregular names.

Tool Count5/5

Six tools is an appropriate number for a sensitive info scanning and masking server. Each tool covers a necessary operation without redundancy or excessive specialization.

Completeness4/5

The tool set covers core workflows: scanning (file and text), masking (file and text), report generation, and rule listing. A minor gap is the lack of rule management tools (add/modify rules), but the primary detection and masking functionality is complete.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

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

PDF Redaction MCP AOAuth
com.pdf-redaction
MCP server for detecting and redacting PII (Personally Identifiable Information) in PDF documents.
File Systems Security
23
Data Compliance Classifier MCP A
io.github.OjasKord
Classify data safety before storing or sharing. GDPR, HIPAA, PCI-DSS, CCPA. AI-powered.
Legal & Compliance AI & Machine Learning Security
32
mcp-agentcore A
com.geiant
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Legal & Compliance AI & Machine Learning Government Data
32
Scrub MCP A
com.malgorath.scrub-mcp
Stateless PII redaction over MCP/REST. Free ≤1000 words or $0.01/call; file upload supported.
Security Legal & Compliance
1

Related MCP Servers

mcp-server-conceal
Security
gbrigandi
A
license
Not graded
quality
C
maintenance
An MCP proxy that pseudo-anonymizes PII before data reaches external AI providers like Claude, ChatGPT, or Gemini.
Updated a year ago (2025-07-24 06:26 UTC)
18
MIT
MCP Presidio
Security Data Platforms App Automation
cmalpass
A
license
A
quality
D
maintenance
An MCP server that enables LLMs to detect and anonymize over 25 types of Personally Identifiable Information (PII) using Microsoft Presidio. It supports various redaction strategies and can process both plain text and structured data to help ensure data privacy.
Updated 9 months ago (2025-12-10 22:26 UTC)
10
MIT
pii-anonymizer
Security AI & Machine Learning
kofi-sketch
F
license
Not graded
quality
D
maintenance
MCP server for automatic detection and redaction of PII in text, with anonymization and deanonymization capabilities, all local processing.
Updated 6 months ago (2026-03-17 16:17 UTC)
1
-
wardcat-mcp
Security
oguzhantopcu0
A
license
A
quality
B
maintenance
MCP server providing on-prem PII detection and anonymization tools (scan and is_sensitive) for AI agents, ensuring data stays local.
Updated 2 months ago (2026-07-14 15:34 UTC)
4
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/hawklithm/sensitive-info-mcp'

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