Skip to content

fix(schema): make tool schemas provider compatible#50

Open
franktronics wants to merge 1 commit into
Dokploy:mainfrom
franktronics:fix/provider-compatible-schemas
Open

fix(schema): make tool schemas provider compatible#50
franktronics wants to merge 1 commit into
Dokploy:mainfrom
franktronics:fix/provider-compatible-schemas

Conversation

@franktronics

Copy link
Copy Markdown

Summary

Fix MCP tool schema compatibility with providers that strictly validate JSON Schema before accepting tools.

This covers schema failures such as:

  • regex lookaround is not supported on email fields
  • invalid pattern errors on password fields
  • clients querying resources/list or prompts/list and receiving Method not found

Changes

  • Strip provider-incompatible pattern keywords from published tool input schemas.
  • Keep runtime Zod validation unchanged for tool execution.
  • Keep JSON Schema draft 2020-12 on top-level input schemas.
  • Return empty lists for resources, resource templates, and prompts when clients query them.
  • Add regression tests to ensure:
    • tool schemas do not expose pattern
    • nested $schema keys are stripped
    • resources/list, resources/templates/list, and prompts/list succeed

Related work

This builds on the same compatibility issue addressed in #47.

PR #47 removes the known provider-incompatible email lookaround patterns from generated schemas. This PR keeps that fix and generalizes the protection at the MCP tools/list boundary by stripping all pattern keywords from published input schemas, while preserving runtime Zod validation.

That also covers additional provider failures, such as password regex patterns rejected by DeepSeek-compatible providers.

Why

#47 fixed the known email lookaround regex issue, but other generated pattern keywords can still be rejected by strict providers. For example, DeepSeek rejects password patterns such as databasePassword.pattern.

Because these schemas are generated from OpenAPI and consumed by multiple providers with different JSON Schema subsets, the safer MCP boundary is to publish provider-compatible schemas and keep strict validation on the server side.

Testing

  • npx --yes pnpm@10.24.0 test -- src/server.test.ts
  • npx --yes pnpm@10.24.0 type-check
  • npx --yes pnpm@10.24.0 lint
  • npx --yes pnpm@10.24.0 build

Manual smoke check:

  • tools/list returns 524 tools
  • published tool schemas contain 0 pattern keywords
  • resources/list returns []
  • resources/templates/list returns []
  • prompts/list returns []

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant