Bug
Tool schemas containing the bitbucketEmail / letsEncryptEmail / email regex pattern are rejected by OpenAI's tool schema validator and Anthropic Sonnet (strict mode) because the pattern uses regex lookarounds ((?!...)), which neither validator supports.
Session error: Invalid JSON schema: regex lookaround is not supported.
Found at $.properties.bitbucketEmail.pattern.
This is distinct from #43 (which is about invalid char-class regex in databasePassword). Same family of bug — schemas generated from upstream OpenAPI that LLM JSON-Schema validators don't accept — but a different root pattern.
It is also distinct from closed #32 — that fix (#33) made the SDK emit JSON Schema draft 2020-12 so the schema declaration is correct. Draft 2020-12 permits lookarounds (ECMA-262), but OpenAI's tool-schema validator explicitly rejects them regardless of declared draft version.
Affected tools
All bitbucket-*, domain-*, and user-* tools that take an email field. In @dokploy/mcp@0.29.3, every occurrence is the same generated pattern (7 hits in build/generated/tools.js):
.email().regex(new RegExp("^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"))Tools confirmed affected:
bitbucket-createbitbucket-testConnectionbitbucket-updatesettings-assignDomainServer (letsEncryptEmail)user-updateuser-createUserWithCredentialsorganization-inviteMember
Steps to Reproduce
- Configure
@dokploy/mcp@0.29.3 with an OpenAI model (GPT-5.x) or Anthropic Sonnet in strict mode as the LLM.
- Start a session — the MCP server sends
tools/list.
- The provider validator rejects the schema with the lookaround error above.
- Session never starts; affected agent/category hangs or fails outright.
Provider-by-provider verification
Tested with opencode orchestrator:
| Provider |
Result |
| Anthropic Opus 4.7 (lookaround-tolerant) |
✅ Works |
| Anthropic Haiku 4.5 |
✅ Works |
| OpenAI GPT-5.5 |
❌ regex lookaround is not supported |
| Anthropic Sonnet 4.6 strict |
❌ Same error |
| (Reporter from #43) DeepSeek |
❌ Same error class |
Root Cause
The lookaheads (?!\.) and (?!.*\.\.) in the email regex are an OpenAPI-spec artifact (presumably from Dokploy's better-auth email validation pattern), passed through openapi-to-zod and then through zod-to-json-schema. JSON Schema draft 2020-12 technically allows lookarounds (ECMA-262), but provider validators (OpenAI, Anthropic Sonnet strict) implement only the safer ECMA-262 core subset.
Suggested Fix
The simplest fix is to drop the .regex(...) call entirely in the codegen path for email-format fields — z.string().email() already validates RFC-compliant emails, and the additional lookaround pattern is redundant cosmetic enforcement:
- z.string().email().regex(new RegExp("^(?!\\.)(?!.*\\.\\.)..."))
+ z.string().email()Alternatively, replace the OpenAPI source pattern with a non-lookaround equivalent (e.g., ^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$) so codegen produces a portable JSON Schema pattern.
Local Workaround
For users hitting this today, the lookaround can be stripped from the installed package:
perl -i -pe 's|\.email\(\)\.regex\(new RegExp\("\^\(\?\![^"]*"\)\)|.email()|g' \
node_modules/@dokploy/mcp/build/generated/tools.jsThis removes the 7 lookaround patterns in v0.29.3 and lets OpenAI / Sonnet-strict use the dokploy MCP tools.
Environment
@dokploy/mcp@0.29.3 (latest as of 2026-05-25)@modelcontextprotocol/sdk@1.29.0- Tested via
opencode orchestrator with multiple model providers
- macOS 15
Related
Bug
Tool schemas containing the
bitbucketEmail/letsEncryptEmail/emailregex pattern are rejected by OpenAI's tool schema validator and Anthropic Sonnet (strict mode) because the pattern uses regex lookarounds ((?!...)), which neither validator supports.This is distinct from #43 (which is about invalid char-class regex in
databasePassword). Same family of bug — schemas generated from upstream OpenAPI that LLM JSON-Schema validators don't accept — but a different root pattern.It is also distinct from closed #32 — that fix (#33) made the SDK emit JSON Schema draft 2020-12 so the schema declaration is correct. Draft 2020-12 permits lookarounds (ECMA-262), but OpenAI's tool-schema validator explicitly rejects them regardless of declared draft version.
Affected tools
All
bitbucket-*,domain-*, anduser-*tools that take an email field. In@dokploy/mcp@0.29.3, every occurrence is the same generated pattern (7 hits inbuild/generated/tools.js):Tools confirmed affected:
bitbucket-createbitbucket-testConnectionbitbucket-updatesettings-assignDomainServer(letsEncryptEmail)user-updateuser-createUserWithCredentialsorganization-inviteMemberSteps to Reproduce
@dokploy/mcp@0.29.3with an OpenAI model (GPT-5.x) or Anthropic Sonnet in strict mode as the LLM.tools/list.Provider-by-provider verification
Tested with
opencodeorchestrator:regex lookaround is not supportedRoot Cause
The lookaheads
(?!\.)and(?!.*\.\.)in the email regex are an OpenAPI-spec artifact (presumably from Dokploy'sbetter-authemail validation pattern), passed throughopenapi-to-zodand then throughzod-to-json-schema. JSON Schema draft 2020-12 technically allows lookarounds (ECMA-262), but provider validators (OpenAI, Anthropic Sonnet strict) implement only the safer ECMA-262 core subset.Suggested Fix
The simplest fix is to drop the
.regex(...)call entirely in the codegen path foremail-format fields —z.string().email()already validates RFC-compliant emails, and the additional lookaround pattern is redundant cosmetic enforcement:Alternatively, replace the OpenAPI source pattern with a non-lookaround equivalent (e.g.,
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$) so codegen produces a portable JSON Schema pattern.Local Workaround
For users hitting this today, the lookaround can be stripped from the installed package:
perl -i -pe 's|\.email\(\)\.regex\(new RegExp\("\^\(\?\![^"]*"\)\)|.email()|g' \ node_modules/@dokploy/mcp/build/generated/tools.jsThis removes the 7 lookaround patterns in v0.29.3 and lets OpenAI / Sonnet-strict use the dokploy MCP tools.
Environment
@dokploy/mcp@0.29.3(latest as of 2026-05-25)@modelcontextprotocol/sdk@1.29.0opencodeorchestrator with multiple model providersRelated
databasePasswordchar-class pattern