How do I use regex-mcp?

1. Click on "Deploy 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., "@regex-mcp test pattern \d{3}-\d{2}-\d{4} on 'My SSN is 123-45-6789.'" 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.

regex-mcp

by MuhammadAliShahzad

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

regex-mcp

npm version License: MIT

MCP server for testing, explaining, debugging, and generating regular expressions. Works with any MCP client — Claude Code, Cursor, VS Code Copilot, Windsurf, and more.

Never leave your editor for regex again.

Features

Test — Run patterns against text with highlighted matches, capture groups, and coverage stats
Explain — Token-by-token breakdown with nested group indentation
Validate — Syntax checking with common pitfall warnings (greedy traps, anchor issues, unescaped dots)
Replace — Find and replace with capture group references ($1, $2)
Debug — Visual match markers with smart hints when patterns fail (case, anchors, whitespace, multiline)
Generate — Natural language to regex for 25+ common patterns (email, URL, UUID, date, phone, etc.)

Related MCP server: rxjs-mcp-server

Install

Claude Code

claude mcp add @muhammadalishahzad/regex-mcp -- npx -y @muhammadalishahzad/regex-mcp

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "regex": {
      "command": "npx",
      "args": ["-y", "@muhammadalishahzad/regex-mcp"]
    }
  }
}

Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "regex": {
      "command": "npx",
      "args": ["-y", "@muhammadalishahzad/regex-mcp"]
    }
  }
}

VS Code Copilot

Add to .vscode/mcp.json:

{
  "servers": {
    "regex": {
      "command": "npx",
      "args": ["-y", "@muhammadalishahzad/regex-mcp"]
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "regex": {
      "command": "npx",
      "args": ["-y", "@muhammadalishahzad/regex-mcp"]
    }
  }
}

Tools

`regex_test`

Test a pattern against input text. Returns highlighted matches, positions, capture groups, and coverage stats.

Pattern: \d+
Input:   "Order #123 has 4 items at $99.50"

Found 4 matches (8 chars, 25.0% of input)

Highlighted: Order #[123] has [4] items at $[99].[50]

Match 1:
  Text:     "123"
  Position: 7–10
  Length:   3

Match 2:
  Text:     "4"
  Position: 15–16
  Length:   1

`regex_explain`

Token-by-token breakdown with group indentation for nested patterns.

Pattern: (?:https?://)([\w.-]+)(?:/(\w+))?

Breakdown:
  (?:          → start non-capturing group
    h          → literal 'h'
    t          → literal 't'
    t          → literal 't'
    p          → literal 'p'
    s          → literal 's'
    ?          → optional (zero or one)
    :          → literal ':'
    /          → literal '/'
    /          → literal '/'
  )            → end group
  (            → start capture group
    [\w.-]     → any character in [\w.-]
    +          → one or more times
  )            → end group
  (?:          → start non-capturing group
    /          → literal '/'
    (          → start capture group
      \w       → any word character (a-z, A-Z, 0-9, _)
      +        → one or more times
    )          → end group
  )            → end group
  ?            → optional (zero or one)

`regex_validate`

Check syntax and detect common pitfalls.

Pattern: ^.*foo.bar$
Flags:   g

Valid regex pattern.

Flags:
  g — global — find all matches

Warnings (3):
  1. Unescaped '.' matches ANY character. Did you mean '\.'?
  2. '.*' is greedy — it matches as much as possible. Consider '.*?'
  3. Using anchors (^/$) with global flag (g). Add 'm' for per-line matching.

`regex_debug`

Visual debugging with smart hints when patterns don't match.

Pattern: /^Hello/g
Input:   "hello world" (11 chars)

Result: No matches.

Hints:
  1. Case mismatch: With the 'i' flag, the pattern matches 1 time(s).

When matches are found, shows visual markers:

Found 2 matches:

  "Error on line 42: timeout. Error on line 99: crash."
   ^^^^^^^^^^^^^^^                ^^^^^^^^^^^^^^^^^^^^^

Match 1 [0–15]: "Error on line 42"
  Context: [Error on line 42]: timeout. Err...

Match 2 [27–52]: "Error on line 99: crash."
  Context: ...timeout. [Error on line 99: crash.]

`regex_replace`

Find and replace with capture group support.

Pattern:     (\w+), (\w+)
Input:       "Doe, John"
Replacement: $2 $1

Replacements: 1

Before:
Doe, John

After:
John Doe

`regex_generate`

Generate regex from natural language descriptions. Supports 25+ common patterns.

Description: "email address"

Best match:
  Pattern: [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}
  Description: Matches most common email address formats

Available categories: email, URL, IPv4, phone, date (ISO/US), time, hex color, UUID, number, decimal, HTML tag, credit card, ZIP code, MAC address, slug, camelCase, snake_case, password validation, JSON key, Markdown link, file extension, semver, and more.

Development

git clone https://github.com/MuhammadAliShahzad/regex-mcp.git
cd regex-mcp
npm install
npm run build

Test with the MCP Inspector:

npm run inspector

Run the server directly:

node build/index.js

How it works

regex-mcp runs as a local stdio process — no network calls, no API keys, no LLM dependencies. All regex operations use the native JavaScript RegExp engine. Pattern explanation uses a built-in tokenizer, not AI.

License

MIT

Available Tools

6 tools

regex_debugA

Debug a regex pattern against input text. Shows match positions, visual markers, context, and hints when no match is found.

ParametersJSON Schema

Name	Required	Description
`pattern`	Yes	Regular expression pattern
`input`	Yes	Text to debug against
`flags`	No	Regex flags. Default: g (global)

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool shows detailed match information and hints on no match, which are key behaviors. However, it does not describe the exact output format or mention any side effects (none expected), but it is sufficiently transparent for a debug tool.

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 only two sentences, front-loaded with the primary purpose, and each sentence adds value. No unnecessary words or repetition.

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?

For a tool with 3 simple parameters and no output schema or annotations, the description covers the core functionality and output details. It does not mention edge cases or performance, but it is sufficiently complete for an agent to understand what the tool does.

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?

Schema coverage is 100% with descriptions for all parameters. The tool description does not add extra semantic value beyond what is already in the schema. It mentions 'input text' but that is implicit in the schema. Hence, baseline score of 3.

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 'Debug a regex pattern against input text' with a specific verb and resource. It describes outputs (match positions, visual markers, context, hints) that distinguish it from sibling tools like regex_test (simple match check) or regex_explain (pattern explanation).

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?

The description implies usage for debugging regex but does not explicitly mention when not to use it or compare to sibling tools. While the verb 'debug' conveys intent, there is no direct guidance like 'Use this tool to visualize matches; for a simple pass/fail test, use regex_test instead.'

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

regex_explainB

Get a human-readable, token-by-token explanation of a regex pattern.

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	Yes	Regular expression pattern to explain

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states what the tool does, but omits critical details such as error handling (e.g., invalid patterns), performance characteristics, or whether the explanation is returned as plain text or structured data.

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 a single, efficient sentence that front-loads the key action ('Get') and clearly conveys the tool's purpose without any extraneous words.

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 one parameter and no output schema. The description mentions the output is a 'human-readable, token-by-token explanation' but does not specify the format (e.g., text, JSON, list). This is minimally adequate for such a simple tool, but could be more 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?

Schema coverage is 100%, so the input schema already describes the 'pattern' parameter. The description adds that the output is a 'human-readable, token-by-token explanation,' but does not add additional meaning to the parameter itself beyond what the schema provides.

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 'Get' and the resource 'a human-readable, token-by-token explanation of a regex pattern.' This is specific and distinct from sibling tools like regex_test or regex_validate, which serve different purposes.

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 does not provide any guidance on when to use this tool versus alternatives. For example, it doesn't mention that this tool is for understanding a regex rather than testing or debugging it, nor does it suggest when not to use it.

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

regex_generateA

Generate a regex pattern from a natural language description. Supports common patterns like email, URL, IP, phone, date, UUID, and more.

ParametersJSON Schema

Name	Required	Description	Default
`description`	Yes	Describe what you want to match, e.g. 'email address' or 'date in YYYY-MM-DD format'

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It states the core functionality but does not disclose output format, limitations, or error handling. For a simple tool, this is minimally adequate.

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?

Two sentences with no wasted words. The first sentence defines the action, the second gives concrete examples. Perfectly concise.

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's simplicity (one parameter, no output schema), the description covers the essential purpose and input. It could mention that the output is a regex string, but this is implied.

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?

The schema provides a description for the parameter, but the tool description adds examples of supported patterns (email, URL, IP, etc.), which enriches understanding beyond the schema.

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 'generate' and the resource 'regex pattern', and distinguishes from siblings like regex_debug, regex_explain, etc. by focusing on generation from natural language.

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

Usage Guidelines4/5

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

The description implies when to use (when you need a regex for common patterns), but does not explicitly list alternatives or when not to use it. The sibling tools provide context, but the description could be more direct.

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

regex_replaceB

Find and replace text using a regex pattern. Supports capture group references ($1, $2, etc.) in the replacement string.

ParametersJSON Schema

Name	Required	Description
`pattern`	Yes	Regular expression pattern to match
`input`	Yes	Text to perform replacement on
`replacement`	Yes	Replacement string. Use $1, $2 for capture groups, $& for full match.
`flags`	No	Regex flags. Default: g (global)

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description discloses the core behavior (find and replace with capture group support). However, it omits details like default global flag, error handling for invalid patterns, or whether the replacement is case-sensitive. The description is adequate but not richly transparent.

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?

Two concise sentences with no redundant information. The description is front-loaded with the main purpose and adds a key feature. Every sentence earns its place.

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?

For a simple utility with full schema parameter descriptions, the description is minimally complete. However, without an output schema, the agent does not know the return format (e.g., replaced string or count). Lack of examples or error behavior are gaps.

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?

Schema coverage is 100%, so baseline is 3. The description adds that capture group references are supported, but this is already detailed in the replacement parameter description. It does not add new semantic value beyond what the schema provides.

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 'find and replace text using a regex pattern', which is a specific verb-resource combination. It distinguishes itself from sibling tools like regex_test (testing) and regex_explain (explanation). However, it could be more precise by explicitly saying 'performs regex substitution'.

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 like regex_test or regex_debug. There is no mention of alternatives or exclusion criteria. The description implies usage but does not offer explicit contextual guidance.

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

regex_testA

Test a regex pattern against input text. Returns all matches with positions and capture groups.

ParametersJSON Schema

Name	Required	Description
`pattern`	Yes	Regular expression pattern
`input`	Yes	Text to test against
`flags`	No	Regex flags: g (global), i (case-insensitive), m (multiline), s (dotAll), u (unicode). Default: g

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses return behavior (matches, positions, capture groups) but lacks details on error handling, edge cases (no matches, invalid patterns), or performance.

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?

Single sentence, front-loaded with key information. No redundant words.

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?

No output schema; description briefly explains return value but lacks specifics on structure (array of objects? key names?). Basic but incomplete for complex regex results.

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?

Schema coverage is 100%, and description doesn't add significant meaning beyond schema. It mentions the purpose but no additional parameter context beyond schema descriptions.

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?

Clearly states the tool tests a regex pattern against input text and returns matches with positions and capture groups. Differentiates from siblings like regex_replace or regex_validate.

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 guidance on when to use this tool over alternatives. While the purpose is clear, the description doesn't contrast with siblings like regex_debug or regex_explain.

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

regex_validateB

Check if a regex pattern is syntactically valid and describe the flags used.

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	Yes	Regular expression pattern to validate
`flags`	No	Regex flags to validate

TDQS

B3.4/5.0

Behavior3/5

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

No annotations provided; the description states core behavior (syntax check + flag description) but lacks details like return format, potential destructive effects (none expected), or behavior on invalid input. Adequate but minimal.

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?

Single sentence, no extraneous information. Front-loaded with action and resource.

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?

No output schema; description fails to specify return type or structure. For a validation tool, what is returned (boolean, string with errors, etc.) is critical and missing.

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?

Schema coverage is 100% with basic descriptions. The description adds that validation is for 'syntactic validity' and mentions 'describe the flags used', which is slightly beyond schema but not significantly enhancing parameter understanding.

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 checks syntactic validity of a regex pattern and describes flags. It distinguishes from siblings like regex_test (tests against a string) and regex_explain (explains pattern), so purpose is specific.

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 (e.g., regex_test for matching, regex_explain for explanation). The description only states what it does, without context for selection.

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.

6 tool updatesv1.1.0May 27, 2026
- First observedregex_debug
- First observedregex_explain
- First observedregex_generate
- First observedregex_replace
- First observedregex_test
- First observedregex_validate

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-05-27 01:55 across 6 tools

Disambiguation5/5

Each tool serves a distinct regex operation (debug, explain, generate, replace, test, validate) with clear descriptions that prevent confusion. Even the similar tools regex_debug and regex_test are differentiated by debug's additional detail.

Naming Consistency5/5

All tools follow a consistent 'regex_verb' naming pattern with snake_case, making it predictable and easy for an agent to infer functionality from the name alone.

Tool Count5/5

With 6 tools, the server is well-scoped for a regex utility, covering the most common tasks without being bloated or too sparse.

Completeness4/5

The tool set covers core regex operations, though a potential gap like regex_split is missing. However, the existing tools handle most use cases effectively.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

suma-memory A
io.github.sumanaddanki
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Knowledge & Memory Developer Tools Autonomous Agents
2
MCP Server By TestMu AIOAuth
com.lambdatest.mcp
Run, debug, and triage tests from your IDE using natural language, no dashboard switching, no manual data transfers. The TestMu AI (formerly LambdaTest) MCP Server is a single remote server exposing four tool suites: HyperExecute — analyze your project, generate YAML configs and test runner commands, then monitor jobs and sessions. Automation — pull a TestID's details plus command, network, and console logs into one chat for instant root-cause analysis. Includes mobile app upload. SmartUI — explain pixel, layout, DOM, and perceptual changes in a visual regression run, with context-aware React/HTML/CSS fixes. Accessibility — audit any public URL or a local React app against WCAG and get ready-to-apply remediation steps. Connects over https://mcp.lambdatest.com/mcp using OAuth 2.1 — no API keys in your config. One-click install in Cursor; works with Claude, GitHub Copilot, Cline, and any MCP client. Tests execute on the TestMu AI cloud: 3,000+ browsers and 10,000+ real devices.
Cloud Platforms Testing & QA Tools
1
iHatePosting A
com.ihateposting
Draft, check and schedule posts to your connected social accounts from Claude, ChatGPT or Cursor.
Social Media Marketing
61
AgentSEO B
dev.agentseo.www
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Marketing Browser Automation
454

Related MCP Servers

WebEvalAgent MCP Serverofficial
Browser Automation Testing & QA Tools
refreshdotdev
A
license
A
quality
F
maintenance
Unleashes LLM-powered agents to autonomously execute and debug web apps directly in your code editor, with features like webapp navigation, network traffic capture, and console error collection.
Updated 7 months ago (2026-02-11 14:55 UTC)
2
1,238
Apache 2.0
rxjs-mcp-server
Developer Tools
shuji-bonji
A
license
A
quality
A
maintenance
Execute, debug, and visualize RxJS streams directly from AI assistants like Claude.
Updated 8 days ago (2026-09-07 00:10 UTC)
6
603 npm
4
MIT
RAGex
Search Code Analysis RAG Systems
jbenshetler
F
license
Not graded
quality
C
maintenance
Gives Claude semantic search superpowers to find and reuse existing patterns in your codebase.
Updated a year ago (2025-09-12 17:24 UTC)
16
-
Claude Code Starter Kit MCP
Testing & QA Tools Code Analysis Penetration Testing
dachivadachkoria
A
license
C
quality
C
maintenance
Enables AI-powered automated testing, security scanning, code review, and maintenance tasks directly within Claude Code or desktop.
Updated 6 months ago (2026-03-08 21:09 UTC)
12
4
MIT

regex-mcp

Features

Install

Claude Code

Claude Desktop

Cursor

VS Code Copilot

Windsurf

Tools

regex_test

regex_explain

regex_validate

regex_debug

regex_replace

regex_generate

Development

How it works

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

WebEvalAgent MCP Serverofficial

`regex_test`

`regex_explain`

`regex_validate`

`regex_debug`

`regex_replace`

`regex_generate`