Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ai-security-gateway-mcp Scan this prompt for PII before I send it: my email is john.doe@example.com"
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.
Local PII detection and masking for Claude Desktop, Cursor, and Windsurf. Your prompts are scanned on your machine before reaching any LLM.
Automatically detects and masks sensitive data in your prompts:
📧 Email addresses
📱 Phone numbers (India-friendly)
💳 Credit card numbers
🪪 Aadhaar numbers
📋 PAN cards
🌐 IP addresses
🛂 Passport numbers
🏦 Bank account numbers
Related MCP server: classifinder-mcp
Once installed, Claude Desktop (and Cursor/Windsurf) automatically has access to a scan_prompt tool. You can ask Claude to scan any prompt before sending it, or Claude will proactively suggest scanning when it detects potentially sensitive content.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"ai-security-gateway": {
"command": "npx",
"args": ["-y", "ai-security-gateway-mcp"]
}
}
}npm install -g ai-security-gateway-mcpThen add to claude_desktop_config.json:
{
"mcpServers": {
"ai-security-gateway": {
"command": "ai-security-gateway-mcp"
}
}
}macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
After restarting Claude Desktop, try:
Scan this prompt for PII before I send it: [your text here]Use REPLACE mode to anonymize: [your text here]Is this safe to send to an LLM? [your text here]Mode | Behaviour | Example |
| Partially hides values |
|
| Removes values entirely | (empty) |
| Substitutes typed tokens |
|
Claude Desktop (macOS and Windows)
Cursor
Windsurf
Any MCP-compatible client
All detection runs locally on your machine. No data is sent to any server or cloud service.
npm install
npm run build # compile TypeScript → dist/
npm run dev # run via tsx (no compile step)
npm start # run compiled outputWeb app (v1): https://github.com/dceptev-byte/ai_security_gateway
Scans text for PII (personally identifiable information) before sending to an LLM. Detects emails, phone numbers, credit cards, Aadhaar numbers, PAN cards, IP addresses, passports, and bank accounts. Returns risk level, findings, and anonymized text. Always run this before sending sensitive prompts to any LLM.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | How to handle detected PII: MASK partially hides values, REDACT removes them entirely, REPLACE substitutes typed tokens like [EMAIL] | MASK |
| text | Yes | The prompt text to scan for PII |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of transparency. It discloses detection types, return values (risk level, findings, anonymized text), and implicitly suggests a read-only operation. However, it could be more explicit about whether the input text is mutated, though the 'returns' phrasing implies non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, detection scope, and return/usage guidance. It is front-loaded with the primary action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, detection capabilities, return contract, and usage context. Since there is no output schema, explaining 'returns risk level, findings, and anonymized text' is essential and provided. The tool is simple, and this description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('text' and 'mode'). The description adds no new parameter-level information beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scans text for PII') and clearly identifies the resource (text before LLM). It also lists concrete detection targets (emails, credit cards, etc.), making the tool's purpose unmistakable. Even without siblings, it avoids ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Always run this before sending sensitive prompts to any LLM.' This provides a clear when-to-use directive and implies it as a necessary pre-processing step. No alternatives exist, so no exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.0scan_promptWith only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly defined and distinct.
The tool name 'scan_prompt' follows a clear verb_noun convention, which is consistent even though there is only one tool. No conflicting naming styles are present.
The server is named 'ai-security-gateway', implying a broader set of security functions, but it exposes only a single tool. This feels far too thin for the apparent scope, which likely requires multiple operations like output scanning or configuration.
The server only scans input prompts for PII and anonymizes them. It lacks other critical gateway features such as output scanning, response filtering, or policy management, making the surface severely incomplete for a security gateway.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Detects and redacts PII (emails, phones, SSNs, names, addresses) from text. $0.02/call via x402.
Prompt injection detection API for AI agents. Scan untrusted text before passing it to an LLM.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Deterministic trust gate for AI output: leaked-secret, prompt-injection & PII in one call.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dceptev-byte/ai-security-gateway-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
