Skip to content

fix(binding-mcp-openapi): advertise additionalProperties in generated tool input schema - #2543

Merged
jfallows merged 2 commits into
developfrom
claude/github-issue-2542-z1abis
Sep 4, 2026
Merged

fix(binding-mcp-openapi): advertise additionalProperties in generated tool input schema#2543
jfallows merged 2 commits into
developfrom
claude/github-issue-2542-z1abis

Conversation

@jfallows

@jfallows jfallows commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Description

McpOpenapiCompositeGenerator#inputSchema() builds the MCP tools/list inputSchema for an operation from its OpenAPI requestBody schema, but only ever walked the schema's named properties — it never consulted additionalProperties. This meant that even after #2538 widened update_connector_config/validate_connector_config's requestBody schema to declare "additionalProperties": true, the declared MCP tool schema still only advertised a fixed, narrow set of named properties (connector.class, tasks.max), with no indication that other connector-specific fields (file, topic, name, etc.) are accepted.

A strict MCP client that validates its tools/call arguments against the declared inputSchema before sending a request has no way to know such extra fields are valid, since the schema doesn't declare them — even though the outbound request body projector (bodySchema()) already honors additionalProperties when shaping the actual HTTP request.

inputSchema() now carries a requestBody schema's additionalProperties through into the generated tool schema the same way bodySchema() already does, so the declared schema matches what the operation actually accepts.

This is a fix to binding-mcp-openapi's own schema-generation contract — it applies to any operation routed through this binding whose requestBody schema combines named properties with additionalProperties, not just kafka-connect's operations.

Added McpOpenapiCompositeGeneratorTest#shouldAdvertiseAdditionalPropertiesInInputSchema, confirmed it fails without the fix (getBoolean("additionalProperties") finds no such key) and passes with it. Also re-ran binding-mcp-kafka-connect's existing composite generator tests to confirm no regression.

Fixes #2542

Test plan

  • McpOpenapiCompositeGeneratorTest (57 tests, runtime/binding-mcp-openapi) — all green, including the new regression test
  • Confirmed the new test fails against the pre-fix code and passes against the fix
  • McpKafkaConnectCompositeGeneratorTest (runtime/binding-mcp-kafka-connect) — all green
  • checkstyle:check and license:check clean on changed files

🤖 Generated with Claude Code

https://claude.ai/code/session_01XfmxFqiPhX8PAR1QXGC1Gr


Generated by Claude Code

… tool input schema

McpOpenapiCompositeGenerator#inputSchema() built the MCP tools/list
inputSchema from an operation's requestBody by walking only its named
properties, silently dropping additionalProperties even where the
OpenAPI requestBody schema itself declares one (e.g. an open,
arbitrary-key/value config map). A strict MCP client that validates
its tools/call arguments against the declared inputSchema before
sending a request has no way to know such extra fields are accepted,
even though the outbound body projector (bodySchema()) already honors
additionalProperties when shaping the actual request.

inputSchema() now carries a requestBody schema's additionalProperties
through into the generated tool schema, the same way bodySchema()
already does, so the declared schema matches what the operation
actually accepts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XfmxFqiPhX8PAR1QXGC1Gr
…tools/list schema

McpKafkaConnectProxyIT#shouldListTools asserts the exact tools/list response
against the tools.list spec's hardcoded expected payload. The previous commit
widened update_connector_config/validate_connector_config's declared
inputSchema to carry additionalProperties through from their OpenAPI
requestBody, so the fixed eighteen-tool payload this script expects needs to
match.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XfmxFqiPhX8PAR1QXGC1Gr

jfallows commented Sep 4, 2026

Copy link
Copy Markdown
Contributor Author

CI's Build (25) failed on McpKafkaConnectProxyIT.shouldListTools — that spec script hardcodes the exact expected tools/list JSON response, and I'd only updated the schema generator, not that expectation. Pushed 9654a08 updating update_connector_config/validate_connector_config's expected inputSchema in specs/binding-mcp-kafka-connect.spec/.../tools.list/client.rpt to include "additionalProperties":true, matching the generator's new output. Verified locally: McpKafkaConnectProxyIT, McpKafkaConnectClientIT, and the spec module's peer-to-peer ITs all pass, plus checkstyle/license clean.


Generated by Claude Code

@jfallows
jfallows merged commit 28563e1 into develop Sep 4, 2026
43 checks passed
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.

kafka_connect validate/update_connector_config: declared tool schema still omits connector-specific fields even though the fix landed functionally

2 participants