Click on "Deploy 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., "@Regex Toolkit MCP Server Extract all URLs from this chat log"
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.
A specialized, high-performance Model Context Protocol (MCP) server engineered to handle complex Regular Expression operations deterministically. This server equips your LLM agents with the ability to securely extract, validate, and mask Personally Identifiable Information (PII) without relying on token-heavy, hallucination-prone AI pattern matching.
Through extensive testing with autonomous data-processing agents, we identified a critical limitation in how Large Language Models handle unstructured text: LLMs are highly inefficient at strict pattern matching.
When tasked with extracting or redacting emails, URLs, or phone numbers from large text blobs (such as chat logs or scraped web pages), an LLM must read every single token. This process:
Consumes massive context windows, driving up inference costs exponentially.
Risks Hallucination: The LLM may "invent" emails that look similar, or miss edge-case formatted phone numbers.
Introduces Privacy Risks: Asking an LLM to process and return raw PII directly exposes sensitive data to the model provider's inference pipeline.
The Regex Toolkit MCP solves this by shifting pattern matching away from the AI and into a deterministic, sandboxed execution environment. By leveraging native regex engines, this MCP server can scan megabytes of text in milliseconds, perfectly extracting or masking data. The LLM only receives the exact structured data it needs, saving thousands of tokens and ensuring absolute accuracy.
Related MCP server: ai-security-gateway-mcp
This server exposes three distinct, highly optimized tools for your AI workflows:
extract_pattern
Function: Scans a large body of raw text and extracts all unique instances of a specified pattern (email, url, or phone).
Use Case: Harvesting links from a scraped webpage or compiling a contact list from unstructured meeting transcripts.
validate_pattern
Function: Strictly validates if a single string perfectly matches a standard email, URL, or international phone format.
Use Case: Data sanitization pipelines where an agent must verify user input before writing to a database.
mask_sensitive_data
Function: Redacts sensitive PII from a text blob by deterministically replacing matches with [REDACTED] tags.
Use Case: Privacy compliance. An agent can use this tool to sanitize logs or customer messages before passing the text to an external analytics API.
Vinkius provides free, highly available edge hosting using secure V8 isolates. Deploying to the Vinkius Edge is the fastest way to make this MCP server accessible to any AI agent anywhere, with sub-millisecond response times and zero maintenance.
Clone this repository
Run the deployment command:
npx mcpfusion deployThat's it. Your MCP server is now live, secure, and ready to be connected to your agents.
👉 Access the Regex Toolkit MCP on Vinkius
Constructed using MCP Fusion for reliable, strictly typed execution.
npm install
npm run devThis server is strictly stateless. It does not store, log, or transmit the text you send it for evaluation. The mask_sensitive_data tool is explicitly designed to help organizations meet GDPR and CCPA compliance requirements by ensuring PII is scrubbed before it hits downstream AI models or storage layers.
[INSTRUCTIONS] Use this tool to harvest specific PII or links from raw text blocks.
Extracts all unique emails, URLs, or phone numbers from a large body of text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The raw input text. | |
| type | Yes | The pattern to extract: "email", "url", or "phone". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations (destructiveHint: false) by stating it extracts 'all unique' items, implying a read-only, non-destructive operation. No contradiction with annotations.
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?
Two concise sentences with front-loaded key information. Every sentence adds value; no wasted words.
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 explains what the tool returns (all unique emails, URLs, or phone numbers) and requires no output schema. It is complete for the tool's simplicity.
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 coverage is 100%. The description does not add meaning beyond the schema's parameter descriptions. Baseline score 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 ('harvest' and 'extract') and resource ('PII or links', 'emails, URLs, or phone numbers') and clearly distinguishes from sibling tools (mask_sensitive_data, validate_pattern) by focusing on extraction.
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 provides clear context for when to use the tool: 'harvest specific PII or links from raw text blocks'. It does not explicitly state when not to use it or list alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[INSTRUCTIONS] Use this before sending sensitive user content to external systems.
Redacts sensitive PII (emails, phones, URLs) from a text blob by replacing them with [REDACTED] tags.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to sanitize. | |
| maskEmails | Yes | Set to true to mask email addresses. | |
| maskUrls | Yes | Set to true to mask web URLs. | |
| maskPhones | Yes | Set to true to mask phone numbers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint: false. The description adds behavioral detail: replacement with [REDACTED] tags, which is not in annotations. However, it does not elaborate on reversibility, output format, or side effects, leaving some gaps. Nevertheless, it improves upon the minimal annotation.
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 two sentences, with a front-loaded directive ('Use this before...') followed by the action. Every word earns its place; no redundancy or unnecessary detail.
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?
For a 4-parameter tool with full schema descriptions and no output schema, the description sufficiently conveys what the tool does and when to use it. The redacted output is implied from the replacement behavior. Sibling context is clear.
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 coverage is 100%, so baseline is 3. The description mentions emails, phones, URLs, corresponding to the boolean parameters, but adds no new semantics beyond the schema's 'Set to true to mask...' descriptions. No additional constraints or format details are provided.
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 clearly states the tool's purpose: redacting sensitive PII (emails, phones, URLs) by replacing them with [REDACTED] tags. It uses a specific verb 'mask' matching the tool name and distinguishes from siblings (extract_pattern, validate_pattern) by focusing on redaction, not extraction or validation.
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 instructs to use this tool before sending sensitive user content to external systems, providing clear context. It implies when not to use (if not sending externally) and the siblings are for different tasks, offering implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[INSTRUCTIONS] Returns true if the string is a valid format, false otherwise.
Validates if a single string perfectly matches an email, URL, or phone format.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The single string to validate (e.g. "user@example.com"). | |
| type | Yes | The pattern type: "email", "url", or "phone". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it returns true/false and validates format, which is transparent for a simple predicate. The annotation indicates non-destructive nature. No contradictions with annotations.
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 short but somewhat redundant: the first sentence restates the return type, and the second sentence repeats the validation purpose. Could be merged into one concise sentence.
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?
For a simple validation tool with complete schema and no output schema, the description is minimally adequate. However, it lacks information on error behavior, format strictness, or any edge cases.
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 coverage is 100%, but the description adds value by explicitly naming the supported formats (email, URL, phone) and clarifying that the output is a boolean. This goes beyond the schema descriptions.
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 clearly states that the tool validates a single string against email, URL, or phone formats, returning a boolean. This differentiates it from sibling tools extract_pattern (likely extracts parts) and mask_sensitive_data (likely masks patterns).
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 implies the tool is for validation of specific formats, but it does not explicitly state when to use this tool versus the siblings or when not to use it. No alternatives are mentioned.
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.
v1.0.0extract_patternmask_sensitive_datavalidate_patternScored across 3 tools
Each tool has a clearly distinct purpose: extracting matches, masking sensitive data, and validating formats. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (extract_pattern, mask_sensitive_data, validate_pattern) with snake_case, making them predictable.
With only 3 tools, the set is minimal but appropriately scoped for a narrow domain of PII handling. It avoids being overly thin for its stated purpose.
The tools cover the essential operations for PII: extraction, masking, and validation. Missing features like custom replacement are minor gaps for this focused toolkit.
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Responsible-AI guardrails for agents: scoring with policy, injection & PII detection, DPDP.
The WAF for agents. Pattern-based + heuristic firewall scans prompts, RAG documents, tool argume...
