Unreleased fix: 0.29.14 still ships a pattern rejected by strict providers ("is not a \"regex\"")

Summary

@dokploy/mcp@0.29.14 (current latest and the only version on npm) exposes a tool schema whose
pattern is rejected by strict provider-side JSON Schema validators, making every tool call fail
for affected models:

invalid_request_error: Invalid schema for function 'dokploy_libsql-create':
"^[a-zA-Z0-9@#%^&*()_+\\-=[\\]{}|;:,.<>?~`]*$" is not a "regex"

The root cause is an unescaped [ inside a character class (...+\-=[\]{}...). JavaScript
treats it as a literal, so the MCP server itself is happy — but Go/Rust regex engines reject it as
ambiguous with nested classes.

The fix already exists in main (117fe9d — "fix: strip unsupported regex patterns from tool
schemas", stripUnsupportedRegexPatterns in src/server.ts), but it has never been released.

Why this still affects users

$ git merge-base --is-ancestor 117fe9d v0.29.14 && echo in-release || echo NOT-in-release
NOT-in-release

$ git tag --contains 117fe9d          # no output — no tag contains it
$ git show v0.29.14:src/server.ts | grep -c usesUnsupportedRegexSyntax
0

$ npm view @dokploy/mcp dist-tags
{ "latest": "0.29.14" }               # published 2026-08-06

The commit's author date (2026-07-05) looks older than the 0.29.14 bump (2026-08-06), which makes
this easy to miss — but it is not an ancestor of the tag, and no tag contains it. Anyone installing
via npx -y @dokploy/mcp gets the unsanitized schemas.

Confirmed against the published tarball:

$ grep -c usesUnsupportedRegexSyntax node_modules/@dokploy/mcp/build/server.js
0

Reproduction

Any OpenAI-compatible gateway forwarding tools to a strict provider. Minimal request:

curl -s "$GATEWAY/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' -d '{
  "model": "<strict-model>",
  "max_tokens": 16,
  "messages": [{"role": "user", "content": "hi"}],
  "tools": [{"type": "function", "function": {
    "name": "dokploy_libsql-create",
    "parameters": {"type": "object",
      "properties": {"databasePassword": {"type": "string",
        "pattern": "^[a-zA-Z0-9@#%^&*()_+\\-=[\\]{}|;:,.<>?~`]*$"}},
      "required": ["databasePassword"]}}}]}'

I bisected 12 candidate patterns to isolate the offending character. Only the bare [ fails —
\-, \], `, {}, | and lookaheads all pass.

Provider backend	Result
Anthropic (opus / sonnet / haiku)	✅ accepted
DeepSeek	❌ is not a "regex"
xAI (grok-4)	❌ Schema validation failed: [standard_violation] /properties/databasePassword/pattern

After escaping to =\[\], the same request succeeds on both DeepSeek and xAI. The escaped form is
semantically identical — I verified acceptance is byte-for-byte equal across all 95 printable ASCII
characters.

Secondary: the v-flag heuristic over-strips

usesUnsupportedRegexSyntax() uses new RegExp(pattern, "v") as the compatibility test. The v
(unicodeSets) flag additionally reserves ( ) [ ] { } / - \ | inside classes, so it rejects many
patterns that providers accept — notably a bare trailing -, as in ^[a-zA-Z0-9._-]+$.

Replaying the exact main logic against the 0.29.14 tool set:

patterns: 10 distinct / 85 occurrences
stripped: 66 occurrences (8 of 10 distinct)
kept:     19 occurrences

Stripped patterns include:

x20  ^[a-zA-Z0-9._-]+$
x 8  ^[a-zA-Z0-9 ._-]{0,500}$
x 5  ^[a-zA-Z0-9._\-/#]+$
x 3  ^--[a-zA-Z0-9-]+(=[a-zA-Z0-9._:/@-]+)?$
x 2  ^[a-z0-9][a-z0-9-]*$
x 2  ^[a-zA-Z0-9][a-zA-Z0-9_.-]*$

I sent all 7 of those to a strict provider (xAI) in a single request: all accepted. So the
current heuristic discards useful validation on ~78% of pattern occurrences to fix one genuinely
broken pattern.

Worth noting the escaped form (=\[\]) also fails the v test — because of the unescaped
{, }, | — yet is accepted by every provider I tested. The v flag is a proxy for provider
strictness, not a match for it.

A narrower test would preserve validation:

function usesUnsupportedRegexSyntax(pattern: unknown): boolean {
  if (typeof pattern !== "string") return false;
  if (/\(\?<?[=!]/.test(pattern)) return true;   // lookarounds
  try { new RegExp(pattern, "u"); } catch { return true; }  // must be valid ECMA-262
  return hasUnescapedOpenBracketInClass(pattern); // the actual offender
}

Suggested resolution

1. Publish a release containing 117fe9d — this alone unblocks everyone on npm. The pinned
   pattern in openapi.json (19 occurrences) can also simply be escaped to =\[\], which is a
   no-op in JS and valid everywhere.
2. Optionally narrow the sanitizer so it stops discarding provider-safe patterns.

Workaround for others hitting this

Escape the bracket in the generated build (idempotent):

node -e 'const fs=require("fs"),f="node_modules/@dokploy/mcp/build/generated/tools.js";
const a=String.raw`_+\\-=[\\]`, b=String.raw`_+\\-=\\[\\]`;
const s=fs.readFileSync(f,"utf8");
fs.writeFileSync(f, s.split(a).join(b));
console.log("fixed:", s.split(a).length-1);'

Then point your MCP client at that local install instead of npx -y @dokploy/mcp, since npx
resolves from its own cache.

Verified end to end: 19 occurrences rewritten, tools/list returns 546 tools with 0 remaining
problematic patterns, and the previously failing DeepSeek/xAI requests now succeed.

Environment

• @dokploy/mcp 0.29.14 (npx -y @dokploy/mcp, stdio transport)
• Node.js 22.23.2, Linux
• MCP client: opencode, routed through an OpenAI-compatible gateway
• Server reports serverInfo: { name: "dokploy", version: "2.0.0" }

Start with commit 117fe9d and stripUnsupportedRegexPatterns in src/server.ts, then compare the fix with the pinned patterns in openapi.json and the generated build. Verify the fix is included in a new release and published tarball, and confirm strict-provider schema validation no longer rejects the affected patterns.