Loading ToolBench
MCP server for testing and validating regex patterns against test cases
MCPGex has 4 tools with explicit definitions visible in the server.py source. All tools have descriptions and input schemas, but quality is inconsistent. Tool names are verb-based and reasonably clear. Schemas are present but several parameters lack descriptions or have minimal context. Error handling exists but is not always actionable. The server stores state in a global list, which is problematic for stateless protocol design. Descriptions are generally adequate (mostly 80-180 chars) but some parameter descriptions are sparse or missing entirely. Output schemas are not explicitly documented, callers must infer structure from the implementation. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite having tools that are clearly read-only (test_regex, get_test_cases) and destructive (clear_test_cases). This is a mid-tier community server with functional basics but significant gaps in production-grade detail.
Add a test case for regex pattern validation. Each test case consists of an input string and the expected match/output.
Clear all test cases to start fresh with new requirements.
Get all current test cases to see what requirements the regex pattern needs to satisfy.
Test a regex pattern against all current test cases to see if it satisfies the requirements.
Global mutable state (test_cases list) violates stateless protocol design. The MCP spec expects each request to be independently processable without server-side state. If the client disconnects mid-workflow, state is lost. If multiple clients connect, they share the same test case list, causing cross-client interference.
Missing tool annotations. clear_test_cases is destructive (irreversible), test_regex and get_test_cases are read-only, but no inputSchema annotations (destructiveHint, readOnlyHint) are present. Clients cannot infer which tools are safe to call speculatively.
No output schema documentation. The tool descriptions do not specify what fields are returned (e.g., test_regex returns a multi-line text summary with pass/fail counts, but the structure is implicit in the code). LLMs cannot plan downstream operations without knowing the output shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Parameter 'groups' in add_test_case is poorly documented. Description says 'array of numbers' but does not explain what these numbers represent (are they 1-indexed capture group numbers? 0-indexed? both?). The validation logic checks len(groups) == len(expected_matches), but this coupling is undocumented and unintuitive.
Error handling in test_regex is not actionable for recovery. When a regex pattern is invalid, it returns 'Invalid regex pattern: {e}', but does not suggest next steps or provide examples of valid patterns. When no test cases exist, the error tells the user to call add_test_case, which is better but still minimal.
get_test_cases and clear_test_cases have minimal descriptions (50 chars each). 'Get all current test cases to see what requirements...' and 'Clear all test cases to start fresh...' do not explain WHEN to call these tools or what an LLM should do with the result.
No validation or constraint documentation for regex pattern parameter. Accepts arbitrary strings, no length limits, no guidance on safe patterns vs. ReDoS-prone patterns. Undocumented constraints invite LLMs to pass unsafe inputs.
Flags parameter in test_regex is documented with 'e.g. i, m, s' but uses informal character list instead of an enum or explicit allowed-values constraint. LLMs cannot confidently validate inputs against an informal list.