Skip to main content
Glama
wedo911

regexguard

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
explain_regexA

Parse a regular expression into a real syntax tree and describe in plain English what it matches. Use this to sanity-check a regex you (or someone else) wrote actually does what you intended, before shipping it.

Args:

  • pattern (string, 1-1000 chars): the regex source, without delimiters (no leading/trailing "/").

Returns: For JSON format: { "explanation": string, "parsed": boolean, "error": string | null } explanation is empty and error is set if the pattern could not be parsed (e.g. unbalanced parentheses, unsupported syntax).

Examples:

  • Use when: "does this regex actually require the string to start with a letter?" -> pass the pattern, read the explanation

  • Don't use when: you need to actually run the regex against text -- this tool never executes the pattern, only analyzes its source

Error Handling:

  • Returns an error (not an exception) if the pattern doesn't parse, with the parser's best guess at where the problem is.

check_redos_riskA

Statically analyze a regex's structure for the two classic causes of catastrophic backtracking: nested quantifiers (e.g. "(a+)+") and ambiguous alternation inside a repeated group (e.g. "(a|a)+"). Both can make a backtracking regex engine take exponential time on a crafted or even accidental non-matching input -- a real, exploitable denial-of-service vector, and a common defect in regexes generated without testing against adversarial input.

This tool NEVER executes the pattern -- it only parses and inspects the pattern's source structure, so it's safe to run on untrusted or deliberately malicious patterns without risk of hanging.

Args:

  • pattern (string, 1-1000 chars): the regex source, without delimiters.

Returns: For JSON format: { "parsed": boolean, "error": string | null, "risk": "safe" | "high" | "critical", "findings": [ { "category": "nested_quantifier" | "ambiguous_alternation", "severity": "high" | "critical", "message": string } ] }

Examples:

  • Use when: "is this regex I just generated safe to run against user input?" -> pass the pattern before using it

  • Use when: reviewing a regex from an untrusted source before adding it to a codebase

  • Don't use when: you need proof a regex is fast on all inputs -- this is a heuristic structural check (no false negatives are guaranteed to be caught), not a formal verifier

Error Handling:

  • Returns an error (not an exception) if the pattern doesn't parse.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.6/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: explain_regex describes what a pattern matches, while check_redos_risk analyzes vulnerability to catastrophic backtracking. They share input format but have no functional overlap, making misselection unlikely.

Naming Consistency5/5

Both tools follow a consistent verb_noun snake_case pattern (explain_regex and check_redos_risk). The naming is predictable and aligns with the domain.

Tool Count4/5

With only two tools, the server is minimally scoped, but for a dedicated regex-analysis utility this is reasonable and each tool addresses a core need. Slightly under typical range but appropriate for the narrow focus.

Completeness5/5

The server covers the essential aspects of regex analysis: comprehension (explain_regex) and security risk (check_redos_risk). Syntax validation is implicitly handled via parse errors. There are no obvious missing operations within the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues