openclaw - 💡(How to fix) Fix OpenAI rejects @softeria/ms-365-mcp-server tool schemas with 'Validation Error: type' [1 participants]

Bug: OpenAI rejects @softeria/ms-365-mcp-server tool schemas with Validation Error: type

Summary

When OpenClaw routes a tool-using request through LiteLLM to OpenAI (gpt-5, gpt-5-mini) with the @softeria/ms-365-mcp-server MCP tools registered, OpenAI returns HTTP 400 with Validation Error: "type" - Input should.... One or more of the 110+ tool definitions exposed by the MS365 MCP server has a JSON Schema type field that OpenAI's strict-mode tool schema validation rejects.

I haven't isolated which specific tool schema triggers the failure (110+ tools, the error doesn't say which one). Filing here so the root cause investigation has a starting point. Could be in @softeria/ms-365-mcp-server's tool definitions, OR in OpenClaw's MCP→OpenAI tool schema translation layer.

Environment

• OpenClaw 2026.4.5 (3e72c03)
• Ubuntu 24.04.4 LTS, Node v24.14.1 via nvm
• LiteLLM proxy with OpenAI configured via gpt-5 and gpt-5-mini model aliases
• MCP server: @softeria/ms-365-mcp-server v0.73.1 (started with --org-mode)

Steps to reproduce

1. Configure mcp.servers.ms365 to launch @softeria/ms-365-mcp-server --org-mode (with the env-propagation workaround from #63394 applied via wrapper script).

2. Configure an OpenClaw agent that uses any LiteLLM-routed primary model (e.g., litellm/claude-haiku-4-5) with a fallback chain that includes gpt-5-mini or gpt-5.

3. Send a message that triggers the agent to call any MS365 tool (e.g., list-calendar-events).

4. Force fallback to OpenAI by either rate-limiting the primary provider or by setting gpt-5-mini as primary directly.

5. Observed: HTTP 400 from OpenAI:

   400 litellm.BadRequestError: OpenAIException - Error code: 400 - {
     'success': False,
     'error': 'Validation Error: "type" - Input should...'
   }

   Note: the error message in our logs was truncated by OpenClaw's diagnostic emit. The full message likely identifies which schema field violates OpenAI's expectation. Worth capturing the full error body when reproducing.

Expected behavior

Either:

• The MS365 tool schemas should be valid for OpenAI's strict-mode tool schema validator (the same way they're valid for Anthropic's tool schema validator), OR
• OpenClaw's MCP→OpenAI translation layer should sanitize the schemas before sending them (e.g., strip unsupported fields, coerce type: ['string', 'null'] to type: 'string' with nullable: true, etc.)

Actual behavior

Tool schemas are passed through to OpenAI as-is, OpenAI rejects with HTTP 400 on the validation error.

Severity

Medium. Anyone using @softeria/ms-365-mcp-server with OpenClaw can't reach OpenAI as a fallback for the agents that have access to MS365 tools. Combined with the Gemini/Vertex thought_signature bug (filed separately), this means the only viable model providers for agents with MS365 tools are Anthropic (until rate-limited). With #63357 (per-turn runtime overhead) and #33-equivalent (env propagation, filed as #63394), this is the third hard-blocker on getting @softeria/ms-365-mcp-server working in OpenClaw.

Workaround

Remove OpenAI (gpt-5, gpt-5-mini) from any LiteLLM fallback chain reachable from agents that have MS365 tools enabled. This narrows the viable fallback providers significantly.

Suggested investigation steps

1. Capture the FULL error body from a reproduction (the truncation in OpenClaw's diagnostic log loses the most useful part — which schema field exactly is failing validation).
2. Enumerate the MS365 tool schemas by calling the MCP server's tools/list method directly via stdio JSON-RPC, then look for schemas with:
   • type arrays (e.g., type: ["string", "null"])
   • Missing type on object properties
   • Conflicting additionalProperties
   • Custom JSON Schema 2020-12 features OpenAI doesn't support
3. Test against OpenAI's tool schema validator (https://platform.openai.com/docs/guides/function-calling#strict-mode) for the suspect schemas in isolation.
4. Decide on fix location: if the issue is the MS365 tool schemas themselves, file in @softeria/ms-365-mcp-server. If the issue is OpenClaw not coercing them to OpenAI's expected format, fix in OpenClaw's MCP→OpenAI translation layer.

Suggested fix paths (depending on root cause)

• If schema-level: open a PR against @softeria/ms-365-mcp-server fixing the offending tool schemas to be OpenAI-strict-mode compatible (likely simple JSON Schema cleanups).
• If translation-layer: add an OpenAI-specific schema sanitizer in OpenClaw's MCP integration layer that strips/coerces JSON Schema features OpenAI doesn't support before forwarding to LiteLLM.

Where this bit us

Synap deployment, 2026-04-08. Same deployment as the related issues. Wiring @softeria/ms-365-mcp-server for pleres + family agents to access Microsoft 365. When Anthropic Haiku rate-limited and the fallback chain reached OpenAI, every tool call failed with this validation error.

Related upstream issues

• #62763, #62764, #62765, #62766, #63357, #63394 (other OpenClaw issues from the same Synap deployment)
• #34-equivalent (Gemini/Vertex thought_signature) — to be filed separately, similar root cause class (provider-specific tool format mismatch)