sensitive-info-mcp

by hawklithm

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 3.3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sensitive-info-mcp MCP server](https://glama.ai/mcp/servers/hawklithm/sensitive-info-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hawklithm/sensitive-info-mcp)

Score Badge

Copy to your README.md:

[![sensitive-info-mcp MCP server](https://glama.ai/mcp/servers/hawklithm/sensitive-info-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hawklithm/sensitive-info-mcp)

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