MCP tool parameters of type "object" are serialized as strings instead of being passed as objects

[e-picas]

Description

When calling MCP tools that have a top-level parameter named body of type object, opencode passes the value as a JSON string instead of a native object. The MCP tool's input validation then fails with:

MCP error -32602: Input validation error: Invalid arguments for tool send-mail: [
  {
    "code": "invalid_type",
    "expected": "object",
    "received": "string",
    "path": ["body"],
    "message": "Expected object, received string"
  }
]

This affects all write tools in @softeria/ms-365-mcp-server where the only required parameter is body: object (e.g. send-mail, create-draft-email, create-calendar-event, send-chat-message). Read-only tools with simple scalar parameters (e.g. list-mail-messages, verify-login) work correctly.

Plugins

@softeria/ms-365-mcp-server (latest, type: local / stdio)

OpenCode version

1.15.5

Steps to reproduce

1. Add @softeria/ms-365-mcp-server as a local MCP in opencode.jsonc
2. Login with ms365_login
3. Ask the assistant to send an email: "send a test email to myself"
4. The tool ms365_send-mail is called — fails with Expected object, received string on the body parameter

Any MCP tool with a single required parameter of type object named body will reproduce this.

Operating System

Ubuntu 22.04

Terminal

Warp

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [MCP] Schema validation fails for tools with multiple discriminated-union/nested-object parameters (e.g. obsidian-mcp-server patch_note, append_to_note) #26277: MCP schema validation fails for tools with nested-object parameters — similar symptom where MCP tool parameters of type object are not handled correctly, leading to validation errors on the server side.

[Keesan12]

If object parameters are arriving as strings, I would check whether there is a JSON stringify boundary happening before the MCP transport layer thinks it has a schema-typed payload.

This is one of those bugs where a receipt helps quickly: original JSON Schema type, model-emitted arguments, post-normalization payload, and the final wire payload handed to the tool transport. Once one boundary serializes early, downstream code can still look "valid" while object tools behave like they got plain text.