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., "@MCPGex test the pattern \d{3}-\d{3}-\d{4} for phone number extraction"
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.
MCP server for finding, testing and refining regex patterns
MCPGex is an MCP server that allows LLMs to test and validate regex patterns against test cases. It provides a systematic way to develop regex patterns by defining or generating expected outcomes and iteratively testing patterns until all requirements are satisfied.
MCPGex is still in its early stages.
Related MCP server: RegexForge
Define the goal: You provide what the goal regex pattern should return. The LLM will generate test cases for you.
Test patterns: The LLM can test different regex patterns against all defined test cases to see which ones pass or fail.
Iterate: Based on the results, the LLM can refine the regex pattern until all test cases pass.
Validate: Once all tests pass, you have a regex pattern that works for your specific use cases.
Go ahead and install through pip:
pip3 install mcpgexIf you want to start the MCP server:
mcpgexYou can also add a configuration. For example, for Claude Desktop, you can have:
{
"mcpServers": {
"mcpgex": {
"command": "python3",
"args": ["-m", "mcpgex"]
}
}
}Then, you will be able to use the server in these tools without having to run the python script manually!
The server provides four main tools:
add_test_caseAdd a new test case with an input string and expected match.
Parameters:
input_string (required): The text to test against
expected_matches (required): The array of substrings that should be extracted/matched
description (optional): Description of what this test case validates
Example:
{
"input_string": "Contact me at john@example.com for details",
"expected_matches": ["john@example.com"],
"description": "Basic email extraction"
}test_regexTest a regex pattern against all current test cases.
Parameters:
pattern (required): The regex pattern to test
flags (optional): Regex flags like 'i' (case-insensitive), 'm' (multiline), 's' (dotall)
Example:
{
"pattern": "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}",
"flags": "i"
}get_test_casesView all currently defined test cases.
clear_test_casesRemove all test cases to start fresh.
Comprehensive testing: Ensure patterns work across various use cases
Iterative improvement: Easy to test and refine patterns
Documentation: Test cases serve as examples and documentation
Confidence: Know your regex works before deploying it
Fully Automated: Give it instructions, let it do the rest
Python 3.8+
MCP library (pip3 install mcp)
This project is open source under the MIT license. Feel free to use and modify as needed.
Add a test case for regex pattern validation. Each test case consists of an input string and the expected match/output.
| Name | Required | Description | Default |
|---|---|---|---|
| input_string | Yes | The input string to test the regex pattern against | |
| expected_matches | Yes | Array of substrings that should be matched/extracted by the regex | |
| groups | Yes | The groups that should be extracted by the regex. This is an array of numbers | |
| description | No | Optional description of what this test case is checking for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose any side effects, persistence, or constraints (e.g., does it overwrite? Are test cases stored?). Only states the basic action.
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 no fluff. The first sentence states the primary action and resource, the second provides the structure of a test case. Well front-loaded.
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?
Adequate for a simple add operation with well-defined parameters in the schema. However, lacks mention of return value or confirmation, and does not address potential constraints like duplicate test 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 description coverage is 100%, and the tool description adds minimal value beyond a summary. It repeats 'input string and expected match/output' but does not clarify groups parameter behavior or optional description.
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 action (add a test case), the resource (regex pattern validation), and the components of a test case. It distinguishes from sibling tools (clear, get, test).
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?
No explicit guidance on when to use this tool versus alternatives like clear_test_cases or test_regex. Missing context about prerequisites or typical workflow order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all test cases to start fresh with new requirements.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the destructive nature ('clear'), but does not mention side effects, recovery, or prerequisites. More detail would be beneficial.
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 a single, concise sentence that efficiently communicates the tool's purpose. No unnecessary words or repetition.
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 tool with no parameters, no output schema, and a simple purpose, the description is nearly complete. It explains what the tool does and why. A minor improvement would be to mention the result (e.g., confirmation of clearing), but it is not required.
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?
There are zero parameters, so the baseline is 4. The description adds no further parameter information, which is acceptable given the tool's simplicity.
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?
Description clearly states the action ('Clear all test cases') and the resource ('test cases'), directly indicating the tool's purpose. It is unambiguously distinct from siblings (add, get, test).
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 includes a hint about usage ('to start fresh with new requirements'), but lacks explicit when-to-use, when-not-to-use, or alternatives. It assumes the agent understands the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all current test cases to see what requirements the regex pattern needs to satisfy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but 'get all' clearly indicates a read-only operation. Could add more detail about side effects, but safe assumption.
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?
One sentence with no wasted words, clearly stating action and rationale.
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?
With no parameters and no output schema, the description fully covers the tool's functionality and context.
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?
No parameters, so schema coverage is 100%. Description adds no parameter info, meeting baseline.
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?
Clearly states 'Get all current test cases' and explains the purpose, distinguishing it from siblings like add_test_case, clear_test_cases, and test_regex.
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 use before testing or adding regex patterns, but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a regex pattern against all current test cases to see if it satisfies the requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | The regex pattern to test | |
| flags | No | Optional regex flags (e.g., 'i' for case-insensitive, 'm' for multiline, 's' for dotall). Default is no flags. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool tests against 'all current test cases', which is key behavioral info. However, it does not mention side effects or return 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?
Single sentence, no filler, front-loaded with the action and resource.
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 the main purpose but lacks details on return value and what 'satisfies the requirements' means. Given the simplicity, it is adequate but incomplete.
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 the description adds minimal value beyond schema. It mentions 'satisfies the requirements' but doesn't elaborate. Baseline 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 'Test' and clearly identifies the resource 'regex pattern' and context 'against all current test cases', distinguishing it from sibling tools like add_test_case and clear_test_cases.
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 usage for testing regex patterns against existing test cases, but does not explicitly state when to use or when to avoid, nor does it compare with siblings. It provides adequate but not thorough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct and non-overlapping purpose: adding test cases, clearing them, getting them, or testing a regex against them. No ambiguity between tools.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_test_case, clear_test_cases), making them predictable and easy to understand.
The server has exactly 4 tools, which is well-scoped for the domain of regex pattern testing. Each tool serves a necessary function without being excessive.
The tool set covers the full lifecycle of managing test cases and testing a regex, including creation, clearing, inspection, and execution. No obvious gaps in functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic regex synthesis from labeled examples. Zero LLM, proof matrix, backtracking audit.
33 tools that make AI write, implement, and verify intent against explicit, testable constraints.
Deterministic validation for AI-generated artifacts: JSON Schema, OpenAPI response, SQL syntax.
Generates unit tests for Python code with coverage before/after reports and concrete edge cases.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PatzEdi/MCPGex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
