fix(mcp): normalize empty parameter-free tool schema before sending to OpenAI (#75362)#75401
Conversation
|
Codex review: needs maintainer review before merge. Summary Reproducibility: unclear. The review failed before ClawSweeper could establish a reproduction path. Next step before merge Review detailsBest possible solution: Retry the Codex review after fixing the execution failure. Do we have a high-confidence way to reproduce the issue? Unclear. The review failed before ClawSweeper could establish a reproduction path. Is this the best way to solve the issue? Unclear. Retry the review first so ClawSweeper can evaluate the actual issue and fix direction. What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 1a796b9700ae. |
|
@clawsweeper automerge |
|
ClawSweeper 🐠 automerge status No new branch changes from this pass. ClawSweeper left the branch untouched instead of making a noisy edit. Executor outcome: no planned fix actions. Worker actions:
No branch push, rebase, replacement PR, merge, or ClawSweeper re-review was started on this pass. fish notes: model gpt-5.5, reasoning high. Automerge progress:
|
a917c71 to
1b8b3a3
Compare
…o OpenAI (openclaw#75362) MCP servers may return inputSchema as { type: "object" } without a properties field, or with properties set to undefined/null. The hasTopLevelObjectSchema guard only checked 'properties' in schemaRecord (key existence) without verifying the value is a real object. This caused such schemas to pass through unnormalized, resulting in OpenAI rejecting them with 'object schema missing properties'. Fix: tighten hasTopLevelObjectSchema to require properties to be a non-null object, and broaden isTypedSchemaMissingProperties to catch properties keys with undefined/null values. Regression of openclaw#60158 (originally fixed by openclaw#60176).
|
🦞🦞 Source: I added |
1b8b3a3 to
764d262
Compare
obviyus
left a comment
There was a problem hiding this comment.
Verified the MCP no-parameter schema regression: typed object schemas with properties: undefined or null now normalize through the shared tool-parameter path before OpenAI strict schema handling.
Maintainer follow-up restored the dropped regression-test wrapper, trimmed the redundant explanatory comment, rebased onto current main, and moved the changelog entry to the active Fixes block with PR attribution.
Local gate: pnpm test src/agents/pi-tools.schema.test.ts src/agents/openai-tool-schema.test.ts and pnpm check:changed.
|
Landed on main. Thanks @SymbolStar. |
Fixes #75362
Summary
MCP servers may return
inputSchemaas{ type: "object" }without apropertiesfield, or withpropertiesset toundefined/null. ThehasTopLevelObjectSchemaguard only checked"properties" in schemaRecord(key existence) without verifying the value is a real object. This caused such schemas to pass through unnormalized, resulting in OpenAI rejecting them with400 Invalid schema for function: object schema missing properties.Root Cause
In
pi-tools-parameter-schema.ts:hasTopLevelObjectSchemachecked"properties" in schemaRecord— which istrueeven when the value isundefinedisTypedSchemaMissingPropertieschecked!("properties" in schemaRecord)— which isfalsewhen the key exists with valueundefinedResult: schemas like
{ type: "object", properties: undefined }passed through without normalization.Fix
hasTopLevelObjectSchemato requirepropertiesto be a non-null objectisTypedSchemaMissingPropertiesto catchpropertieskeys withundefined/null/non-object valuesRegression History
{}→{ type: "object", properties: {} })properties: undefinednot caught)Tests
Added unit tests in:
openai-tool-schema.test.ts: strict mode normalization for empty/undefined propertiespi-tools.schema.test.ts:normalizeToolParameterswithproperties: undefinedandproperties: null