Explain a regex in plain English and detect catastrophic backtracking risk.
Scored across 1 tool
With only one tool, there is no possibility of confusing it with another. The tool's purpose is clearly singular: explaining regular expressions.
The sole tool name 'explain_regex' follows the standard and predictable verb_noun convention. Without additional tools, there are no inconsistencies to penalize.
A single tool feels thin for a server, even though it is a well-designed and appropriately scoped explainer. This falls on the borderline low end of the typical 3-15 tool range.
For the stated domain of explaining regexes, the tool is comprehensive: it parses patterns, explains steps, flags catastrophic backtracking and other dangerous issues, and reports parsing errors. There are no obvious missing operations within the server's singular purpose.
Explain a regular expression in plain English and detect the failure modes that make patterns dangerous rather than merely wrong.
Use this whenever a regex needs to be read, reviewed, or verified — and ALWAYS before putting a pattern somewhere it will run against untrusted input. The critical check is catastrophic backtracking: a pattern like (a+)+$ is three characters longer than a safe equivalent, looks harmless, and takes minutes of CPU on a 30-character input that almost matches. That makes it a denial-of-service vector. Whether a pattern is vulnerable depends on whether nested quantifiers can match the same characters in more than one way, which is a structural property that is unreliable to judge by reading.
It also flags: missing anchors (an unanchored validator accepts any string that merely CONTAINS a valid value), unescaped dots, character ranges like [A-z] that span punctuation, alternation precedence mistakes where an anchor applies to only one branch, and constructs JavaScript does not support.
Input: pattern accepts either a bare pattern or a full /pattern/flags literal. JavaScript syntax; PCRE-only constructs are reported as unsupported rather than guessed at.
Returns: summary (one sentence), steps (an ordered walkthrough), warnings (each with a code, severity, detail, and fix), flagNotes, capture group counts and names, and hasBlockingIssue — check that flag first. If the pattern cannot be parsed it returns an error naming the position, rather than a plausible-looking explanation of something else.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | A JavaScript regular expression, either bare ("^\d+$") or as a full literal ("/^\d+$/gi"). Up to 2000 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint annotation by explaining that the tool checks hasBlockingIssue first, returns structured warnings with severity and fixes, and returns a parse error naming the position on unparseable patterns. It also discloses that PCRE-only constructs are reported as unsupported rather than guessed.
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 lengthy but well-structured, with clear sections for usage, critical risks, flagged issues, input, and return values. Every section earns its place given the tool's security-review purpose, though a tighter opening could help front-load the most important operational details.
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 output schema, the description fully compensates by enumerating the return fields, ordering guidance (check hasBlockingIssue first), and error behavior. The single parameter is thoroughly described in both the schema and description, leaving no critical gap for an agent deciding whether and how to call it.
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?
The schema already fully documents the single pattern parameter, including bare and literal forms, so the baseline is 3. The description adds meaningful nuance by clarifying JavaScript syntax expectations and the tool's behavior toward PCRE-only constructs, which improves call correctness.
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 opens with a specific verb and resource: explaining a regex in plain English and detecting dangerous failure modes, not just correctness. This clearly distinguishes the tool's value proposition even without sibling tools to compare against.
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?
It explicitly says when to use the tool: whenever a regex is read, reviewed, or verified, and always before running against untrusted input. It also provides a concrete security motivation by calling out catastrophic backtracking as a denial-of-service vector.
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.
explain_regexDetects catastrophic-backtracking (ReDoS) regex risk via AST parsing, with JS-safe rewrites.
Cron expression parser: explains any cron + returns next N fire times. Timezone-aware.
Deterministic regex synthesis from labeled examples. Zero LLM, proof matrix, backtracking audit.
Explain cron expressions in English, list next run times, and catch scheduling gotchas.
Add one secure layer between your agents and this server.