Runs regex patterns in JavaScript's RegExp engine via Node.js, returning matches and spans, comparing behavior with Python, converting Python/JavaScript patterns, and verifying compiled results.
Runs regex patterns in Python's re engine, returning matches, spans, groups, and Python-specific behavior, and supports comparing results against other regex engines.
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., "@regexlab-mcp Test ^\d+$ against "123\n" in Python and JavaScript and explain any difference"
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 regex lab for your AI agent: it RUNS the pattern in real engines instead of guessing.
Models write subtly wrong regexes: a $ that accepts a trailing newline, a \d that
matches Arabic digits, a (a+)+ that hangs your server, a (?P<name>...) pasted into
JavaScript. regexlab-mcp is an MCP server that gives the
agent somewhere to check. It runs your pattern in Python re, JavaScript's RegExp (through
node) and, if installed, the third-party regex module, each in a throwaway child process
with a hard timeout, and reports what actually happened.
What is different about it. A few regex MCP servers already exist (for example
regex-check-mcp, which also covers PCRE2 and
RE2, and rexact-mcp); I did not benchmark them
and they cover engines this one does not. The edge here is the combination: one server that
runs the same pattern side by side in several engines and flags disagreements, measures
ReDoS by timing adversarial input in a process that is killed at the budget (not only a static
guess), explains patterns with its own parser and says "not explained" instead of guessing,
translates between Python and JavaScript syntax and compiles the result in the target engine,
previews substitutions with each engine's own template rules, and generates test strings that
are verified by running them. It is pure Python with no dependency beyond mcp.
Real output (Python 3.12, node 24, regex 2026.9):
> test_regex pattern: ^\d+$ subject: "123\n"
case 1: '123\n'
python: 1 match
#1 [0:3] '123'
javascript: no match
regex: 1 match
#1 [0:3] '123'
=> ENGINES DIFFER on this case (see compare_engines for why)
> check_backtracking pattern: (a+)+$ engine: all
RISK: HIGH - catastrophic (exponential) backtracking CONFIRMED by running it.
1. [nested] `(a+)+` repeats something that contains the repeat `a+`, and what follows that
inner repeat can start with the same characters. ...
probe: python: TIMED OUT after 3.0s and was killed, at n~28; last completed n=24 took 1113 ms.
slow input: 'a' * 28 + '!'
> suggest_tests pattern: ^[A-Z]{2}\d{3,4}$
SHOULD MATCH (4 confirmed): 'AA000' 'AA0000' 'ZZ000' 'ZZ0000'
SHOULD NOT MATCH (25 confirmed): 'A000' 'AA00000' 'AA!00' 'aa000' ...
SURPRISES - expected NO match but the engine matched (4):
'AA000\n' matches 'AA000' at [0:5] ['AA000' with a trailing newline]
> convert_pattern (?P<y>\d{4})-(?P=y)\Z python -> javascript
pattern: (?<y>\d{4})-\k<y>(?![\s\S])
VERIFY: the converted pattern compiles in javascript v24.14.0.Related MCP server: RegexForge
Tool | What it does |
| All matches with |
| Token-by-token plain-English breakdown from the server's own parser: classes, greedy/lazy/possessive quantifiers, groups, lookaround, backreferences, anchors, flags, with engine-specific behaviour. Marks unsupported constructs |
| Static scan for nested/overlapping quantifiers plus a timed probe on crafted input, killed at the budget. Reports exponential vs polynomial, with an example slow input. |
| Compiles and runs one pattern everywhere, adds targeted variants (trailing newline, Unicode digits, non-ASCII word, emoji, Turkish case pairs) and lists the known semantic differences that apply. |
| Python to JavaScript and back (named groups, |
| Every substitution and the final text, using each engine's own template syntax ( |
| Should-match / should-not-match strings from the pattern's structure and mutations, all verified by running. Mutations that unexpectedly match are shown as SURPRISES. |
Requires Python 3.10+. For the JavaScript engine install Node.js; for the
regex engine add the extra (regexlab-mcp[regex]). Tools report which engines were skipped.
Claude Code
claude mcp add regexlab -- uvx regexlab-mcp
# with the optional regex module:
claude mcp add regexlab -- uvx --from "regexlab-mcp[regex]" regexlab-mcpClaude Desktop (claude_desktop_config.json)
{
"mcpServers": {
"regexlab": { "command": "uvx", "args": ["regexlab-mcp"] }
}
}Or pip install regexlab-mcp and run regexlab-mcp.
"Write a regex for ISO dates and prove it works on these 10 inputs, in both Python and JavaScript."
"Is ^(\w+\s?)*$ safe to run on user input? Check it."
"Explain (?<=\$)\d+(?:\.\d{2})? token by token."
"This works in Python; make it work in JavaScript and tell me what changed."
"Preview this re.sub on my log line before I run it on the file."
"Give me should-match and should-not-match tests for my phone number regex."
"Why does ^\d+$ accept 123\n in Python but not in the browser?"
Engine | Needs | Notes |
| nothing | Python |
|
| V8 irregexp; |
|
| Possessive/atomic, |
Spans are [start:end) in Unicode code points for every engine (JavaScript's UTF-16 indices
are converted), so results are comparable. Limits: pattern 5000 characters, 100 cases,
200,000 characters of subject in total, 500 matches per case, timeout_s 0.2 to 30.
PCRE2, RE2 and other engines are not included. The explainer covers the common subset; recursion,
conditionals and \N{name} are reported as not explained. The ReDoS static scan is a heuristic
(it can flag shapes that are harmless, and the probe then clears them); "no finding" is evidence,
not proof.
Regexes are untrusted input and can hang an engine for hours, which cannot be interrupted from inside the same process. So:
every run happens in its own child process (a fixed runner script, never eval/exec of user
text); the pattern, flags and subject travel as JSON on stdin and are only ever passed to
re.compile / new RegExp as data;
no shell is used anywhere; the argument vector is fixed by the package;
a hard timeout kills the whole process tree (POSIX process group, Windows Job Object plus
taskkill /T); a test proves a grandchild process dies too;
memory: 1 GiB address-space cap in the Python runner on Linux, a 1 GiB Job Object limit on
Windows, --max-old-space-size=256 for node. macOS has no enforceable address-space limit, so
there only the timeout and the input caps protect you;
subject size, case count, match count, pattern length and captured output are all capped.
The server reads no files and opens no network connections.
uv sync --extra test
uv run pytest tests -v
uv run --with ruff==0.16.0 ruff check src tests
uv run --with mypy==2.3.0 mypy --strict srcTests run real engines in real child processes. JavaScript tests are skipped when node is
missing and regex tests when the module is missing.
Want to build one yourself? regexlab-mcp-the-hard-way is a seven-module tutorial that builds a minimal version of this server step by step.
MIT
Check a regex for catastrophic backtracking (ReDoS) by analysing AND timing it.
Two stages. Static: finds nested quantifiers like (a+)+, alternation with overlapping branches inside a loop, adjacent overlapping repeats like .., and unanchored leading repeats. Empirical: builds adversarial input for the worst suspects and times it in the real engine in a child process that is KILLED at the time limit. A pattern that hits the limit is reported as exponential, with an example slow input. Static suspicions the probe cannot reproduce are reported as unconfirmed; "no finding" is evidence, not proof.
engine: "python" (default), "javascript", "regex", or "all" for every available engine (V8 and Python's re have different optimisations, so results can differ). timeout_s: time budget per probe run, 0.2-30 (default 3).
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| engine | No | python | |
| pattern | Yes | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does so well: it discloses that probing happens in a child process KILLED at the time limit, that static suspicions may be reported as unconfirmed, that "no finding" is evidence not proof, and that V8 vs Python optimisations can produce different answers. That is exactly the kind of execution-model and confidence context an agent cannot infer from the schema.
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?
Front-loaded with the core claim, then a compact "Two stages. Static: … Empirical: …" structure, then per-parameter notes. Every sentence adds information; nothing is padded or repeated from the schema.
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?
An output schema exists, so return-value detail is not needed, and the description covers execution model, confidence semantics, engine differences and the timeout knob. The remaining gap is the undocumented flags parameter and the fact that timeout_s is per-probe while engine="all" multiplies total runtime, which is left implicit.
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 0%, so the description must compensate. It supplies real meaning for engine (listing "python", "javascript", "regex", "all" plus why results differ) and timeout_s (meaning, range 0.2-30, default 3), and pattern is self-evident, but flags receives no explanation at all despite being a free string parameter.
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?
"Check a regex for catastrophic backtracking (ReDoS) by analysing AND timing it" states a specific verb, a specific target condition, and the two mechanisms used. It is immediately distinguishable from siblings like test_regex or explain_regex, which serve different intents.
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 makes clear what the tool is for (ReDoS detection) and how to interpret results (confirmed vs unconfirmed), which implies when to reach for it. However, it never explicitly says when to use this instead of test_regex or compare_engines, nor does it state preconditions such as needing a candidate pattern before deployment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one pattern in every available engine and explain where they differ.
Reports whether the pattern compiles in each engine (named-group syntax (?P vs (?, \A \Z, inline flags, atomic groups, lookbehind width, \p{..}), runs your subject plus targeted variants (trailing newline, Unicode digits, non-ASCII word, emoji, Turkish case pairs) in all engines, and lists the known semantic differences that apply to this pattern ($ and trailing newline, Unicode-aware \d \w \b, dot and line terminators, case folding). Use it when a regex has to behave the same in Python and JavaScript.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| pattern | Yes | ||
| subject | Yes | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses exactly what is checked (per-engine compile status, named-group/\A\Z/inline-flag/atomic-group/lookbehind-width support), the targeted subject variants exercised, and the semantic-difference categories reported. It does not state that the tool is non-mutating or explain what the timeout_s limit does when exceeded, which are the remaining behavioral gaps.
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 purpose sentence is front-loaded and the enumeration of engine differences is dense and informative rather than padded. The parenthetical variant and difference lists are long but each item earns its place by telling the agent what the output will cover.
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?
Output schema exists, so return values need not be explained, and the description is rich about analysis dimensions. But for a 4-parameter tool with 0% schema description coverage and no annotations, leaving 'flags' and 'timeout_s' completely unexplained is a material completeness gap.
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 0%, so the description must compensate, and it largely does not. It implies what 'pattern' and 'subject' mean ('runs your subject plus targeted variants'), but 'flags' and 'timeout_s' are never mentioned, so two of four parameters carry no semantics anywhere.
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?
States a specific verb and resource ('Run one pattern in every available engine') plus the outcome ('explain where they differ'), which clearly separates it from siblings like test_regex (single-engine execution) and explain_regex (pattern explanation). An agent can pick this tool without opening a schema.
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?
Gives explicit when-to-use guidance: 'Use it when a regex has to behave the same in Python and JavaScript.' It does not, however, name the alternative tools (e.g. test_regex or convert_pattern) or state when this is overkill, so the routing is clear but not fully differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a regex between Python and JavaScript syntax, with explicit warnings.
Handles named groups and named backreferences, \A \Z and $ (using exact lookaround equivalents), inline global flags, verbose mode, {,n}, \U and \u{...} escapes, [^] and [], and the g/y/u flags. Things with no equivalent (atomic groups, possessive quantifiers, \p{..} in Python re, POSIX classes, recursion) are left unchanged and listed as WARNINGS. Differences that cannot be fixed syntactically (Unicode-aware \d \w vs ASCII-only) are listed too. The result is compiled in the target engine to prove it is at least valid; run test_regex or compare_engines to prove it is equivalent.
from_engine / to_engine: "python", "javascript" (or "js"), "regex". flags: flags of the source pattern; the converted flags are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| pattern | Yes | ||
| timeout_s | No | ||
| to_engine | Yes | ||
| from_engine | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that unsupported constructs (atomic groups, possessive quantifiers, \p{..}, POSIX classes, recursion) are left unchanged and reported as WARNINGS, and that unfixable semantic differences are listed. It also reveals the verification step of compiling in the target engine. It does not mention the timeout behavior or failure modes for invalid source patterns.
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?
Purpose is front-loaded in a single line, then details follow in a logical order: handled constructs, unhandled constructs, verification path, then parameter notes. The construct catalogue is long but each item informs the agent about coverage limits. Minor waste in the awkward escaped literal rendering (\A \Z, {,n}).
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?
An output schema exists, so return values need no explanation, and the description thoroughly covers conversion scope and warnings. The gaps are the unexplained timeout_s parameter and the absence of any statement about what happens when the target engine rejects the converted pattern, which matters for a tool that admits conversions may be invalid.
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 0%, so the description must compensate. It does supply the allowed values for from_engine and to_engine ("python", "javascript"/"js", "regex") and explains that flags are the source pattern's flags with converted flags returned — genuinely useful given the schema has no enums. However, pattern and timeout_s receive no explanation at all, leaving one of five parameters completely undocumented.
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 opening sentence names a specific verb and resource — translating a regex between Python and JavaScript syntax — and the closing note routes validation work to test_regex and compare_engines. An agent can distinguish this from explain_regex or check_backtracking without opening any schema.
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 states the follow-up condition clearly: use test_regex or compare_engines to prove equivalence, implying this tool only produces a candidate conversion. It gives no explicit when-not-to-use guidance versus explain_regex or replace_preview, but the context is otherwise unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a regex token by token in plain English, using this server's own parser.
Covers literals, escapes, classes, quantifiers (greedy, lazy, possessive), groups
(capturing, named, non-capturing, atomic), lookahead and lookbehind, backreferences,
anchors and inline flags, and says how each construct behaves in the chosen engine
(for example Python's $ before a trailing newline, or JavaScript's ASCII-only
\d). Constructs it does not model (recursion, conditionals, \N{...}) are marked
"NOT EXPLAINED" rather than guessed. Syntax errors are reported with the position.
Engine-specific syntax that the engine would reject is flagged as ERROR.
engine: "python" (default), "javascript" or "regex" (syntax dialect only; this tool does not need the engine installed). flags: same letters as test_regex; they change the explanation (m, s, a, x, ...).
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| engine | No | python | |
| pattern | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the unmodeled-construct policy ('NOT EXPLAINED' rather than guessed), error reporting with position, engine-invalid syntax flagged as ERROR, and that no engine installation is required. These are non-obvious behaviors an agent could not infer from the name or schema.
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?
Front-loaded with the one-sentence purpose, then construct coverage, then edge-case behavior, then the per-parameter notes. Dense but every sentence adds information; the construct enumeration is long but justifies itself by setting scope expectations.
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?
An output schema exists, so return formatting needn't be re-explained, and the description covers engine dialect nuance and failure modes thoroughly for a 3-param, single-pattern tool. Minor gap: no guidance on the 'pattern' input itself or on behavior for very large patterns.
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 0%, so the description must compensate, and it does for two of three params: engine values are enumerated in prose ('python' default, 'javascript', or 'regex' as syntax dialect only) and flags are tied to test_regex letters with examples (m, s, a, x). Only 'pattern' lacks any explicit statement, though the entire description makes its role obvious.
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?
States a specific verb and resource ('Explain a regex token by token in plain English') plus the method ('using this server's own parser'), and the enumerated construct coverage makes it unmistakable versus siblings like test_regex or compare_engines, which operate on matches rather than explanations.
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?
Usage is implied rather than routed: the agent can infer this is for understanding a pattern's semantics, and 'this tool does not need the engine installed' plus the 'same letters as test_regex' cross-reference give useful context. However, it never explicitly says when to prefer test_regex or compare_engines instead, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a regex substitution: every match, what it becomes, and the final text.
The replacement is expanded by each engine's own template rules, so the preview shows what the code will really do. Python uses \1, \g<1> and \g; JavaScript uses $1, $, $&, $` , $' and $$. If the replacement uses the other language's syntax (a common bug: "$1" in Python is literal text) a WARNING says so, and differing results between engines are called out.
engines: any of "python", "javascript" (or "js"), "regex"; default all available.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| engines | No | ||
| pattern | Yes | ||
| subject | Yes | ||
| timeout_s | No | ||
| max_matches | No | ||
| replacement | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that replacement templates are expanded per engine, lists the exact syntax each engine honors, and warns that wrong-language syntax produces a WARNING and divergent results. It omits operational behavior such as what timeout_s and max_matches do when hit, and whether output is truncated.
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 core capability is front-loaded in sentence one, and the engine-syntax detail is genuinely necessary to avoid the '$1' vs '\1' mistake. The engine enumeration at the end is slightly redundant with the earlier syntax discussion and could be tightened.
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?
An output schema exists, so return values need no explanation, but for a 7-parameter tool with zero schema coverage and no annotations the description should cover flags syntax and the effect of timeout_s/max_matches. Missing failure behavior (invalid pattern, timeout exceeded) leaves the agent under-informed about 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 description coverage is 0% across 7 parameters, so the description must compensate. It explains 'engines' thoroughly (accepted values, the 'js' alias, default to all available) and adds real meaning to 'replacement' via engine-specific template syntax, but leaves pattern, subject, flags, timeout_s, and max_matches entirely to their bare titles.
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 first sentence names a specific verb and resource — 'Preview a regex substitution' — and enumerates the output: 'every match, what it becomes, and the final text.' That is clearly distinct from siblings like explain_regex or check_backtracking, though the description never explicitly names an alternative.
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?
Usage is implied by the word 'preview' (check before committing a substitution), but there is no explicit when-to-use guidance, no prerequisites, and no pointer to siblings such as test_regex or compare_engines, which overlap on the cross-engine comparison angle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate should-match and should-not-match test strings for a regex, verified by running.
Builds examples from the pattern's structure (each alternative, quantifier minimum
and maximum, class boundaries) plus mutations (deleted or replaced characters, junk
prefix/suffix, trailing newline, case swap, off-by-one repeat counts), then RUNS all of
them in the real engine. Only confirmed examples are listed as tests. Mutations that
unexpectedly still match are listed as SURPRISES - they often expose a missing anchor,
a $ that accepts a trailing newline, or a class that is too broad. Uses search
semantics (match anywhere), and says when the pattern is not anchored.
engine: "python" (default), "javascript" or "regex" (must be available).
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| engine | No | python | |
| pattern | Yes | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the generation strategy, that examples are RUN and only confirmed ones are listed, that unmatched mutations appear as SURPRISES, and that matching uses search (unanchored) semantics. The main omission is the timeout_s behavior — nothing says what happens when the engine exceeds the budget.
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 core purpose is front-loaded in the first sentence, with the mechanism, verification step, and SURPRISE interpretation following in a logical order. A few clauses restate the same idea (running/verified) but nothing egregious is included.
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 an output schema, the description covers generation logic, verification, result categories, and matching semantics thoroughly. The remaining gap is operational: no mention of timeout behavior or what happens on engine unavailability beyond a bare 'must be available'.
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 0%, so the description must compensate. It does so for `engine` by listing the accepted values and the important caveat that 'javascript'/'regex' must be available, which the schema does not convey via an enum. However, `flags` and `timeout_s` get no explanation at all, leaving half the parameters undocumented in both places.
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 opening sentence names a specific verb and artifact — 'Generate should-match and should-not-match test strings for a regex, verified by running' — which is clearly distinct from siblings like test_regex or explain_regex. It does not explicitly name or route against those siblings, so it stops short of a 5.
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?
Usage is implied rather than stated: the description explains that SURPRISES 'often expose a missing anchor, a `$` that accepts a trailing newline, or a class that is too broad,' which tells the agent why it would want this tool. There is no explicit 'use this instead of test_regex when...' statement or precondition about when generating tests is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a regex against text in REAL engines and report every match.
Use this to check any regex before telling the user it works. For each engine you get all matches (global search) with [start:end) spans in Unicode code points, the numbered and named capture groups, and a flag when engines disagree.
pattern: the regex source, exactly as it would appear in code (no delimiters, no extra string escaping). subject: one text, or a list of texts; each list item is a separate case. flags: letters: i ignore case, m multiline, s dot matches newline, x verbose and a ASCII classes (Python only), u unicode, v unicodeSets and y sticky (JavaScript only). g is implied. engines: any of "python", "javascript" (or "js"), "regex". Default: every engine available on this machine; unavailable ones are reported, not silently skipped. timeout_s: hard limit (0.2-30). A run that exceeds it is killed and reported as a catastrophic-backtracking case. max_matches: cap per case (max 500). Limits: pattern 5000 chars, 100 cases, 200k characters of subject in total.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | ||
| engines | No | ||
| pattern | Yes | ||
| subject | Yes | ||
| timeout_s | No | ||
| max_matches | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden and does so: default is every available engine with unavailable ones reported rather than silently skipped, global search is implied, spans are in Unicode code points, disagreements between engines are flagged, and a timeout is killed and reported as a catastrophic-backtracking case. Hard limits (5000-char pattern, 100 cases, 200k subject chars, 500 match cap) are all disclosed.
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?
Purpose is front-loaded in the first two lines, then parameters are documented one per line in schema order, with limits consolidated at the end. Each line adds non-redundant information; nothing is padding.
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?
An output schema exists so return values need only be sketched, and the description still names spans, capture groups, and disagreement flags. Combined with engine defaults, killing behavior, and size caps, an agent has everything needed to call this correctly on the first try.
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 0%, but the description compensates for all six parameters: pattern format (no delimiters, no extra escaping), subject accepting one text or a list treated as separate cases, per-letter flag semantics including engine-specific ones (a=Python, v/y=JavaScript), engine name aliases and default, timeout range 0.2-30, and max_matches ceiling.
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 first line states a specific verb and resource ('Run a regex against text in REAL engines') plus the output contract ('report every match'), which separates it from explain_regex (explanation) and convert_pattern (translation). The second sentence gives the operational intent, so an agent knows exactly what it gets back without opening the schema.
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?
'Use this to check any regex before telling the user it works' is an explicit when-to-use condition tied to a real workflow. It stops short of naming alternatives or stating when-not-to-use it (e.g. use explain_regex when the user wants an explanation rather than results), so it is strong but not fully routing.
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.
v0.1.0check_backtrackingcompare_enginesconvert_patternexplain_regexreplace_previewsuggest_teststest_regexScored across 7 tools
Each tool has a clearly stated, distinct job: testing, explaining, ReDoS analysis, cross-engine comparison, syntax conversion, substitution preview, and test generation. Minor overlap exists because test_regex already reports engine disagreements and killed timeouts, blurring its boundary slightly with compare_engines and check_backtracking, but the descriptions explicitly cross-reference when to use which.
All seven tools follow a strict snake_case verb_noun convention (test_regex, explain_regex, check_backtracking, compare_engines, convert_pattern, replace_preview, suggest_tests). The verb choice is also semantically meaningful and consistent across the set.
Seven tools is well within the ideal 3-15 range for a regex workbench and each tool covers a genuinely different stage of the regex lifecycle. Nothing appears redundant or thin.
The surface covers validation, explanation, performance safety, portability, conversion, substitution, and test generation—essentially the full regex workflow. Minor gaps remain, such as no explicit tool to list available engines/capabilities or to benchmark raw pattern throughput, but agents can work around these via test_regex output.
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
JSON/YAML, regex, diff, JWT, SQL dialects — the keyless millisecond ops an agent needs mid-task.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
x402 pay-per-call tools for AI agents: code review, data clean, briefs, regex, diff, URL meta.
