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

Activity

1. github-actions

   assigned

   jlongster

   on May 20, 2026
2. github-actions commented on May 20, 2026

   

   github-actionsBot

   on May 20, 2026 – with GitHub Actions

   Contributor

   More 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.
3. Keesan12 commented on May 20, 2026

   

   Keesan12

   on May 20, 2026

   More actions

   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.
4. davilima6 commented on Jun 18, 2026

   

   davilima6

   on Jun 18, 2026

   More actions

   I’m seeing the same kind of failure with the Next.js DevTools MCP integration.

   Versions I tested with:

   • OpenCode: 1.17.8
   • Node: 24.16.0
   • Next.js: 16.2.9
   • Next MCP endpoint: the built-in /_next/mcp endpoint from next-server (v16.2.9)
   • OS: macOS

   The connection itself works. OpenCode can discover the Next MCP server on http://localhost:3000, and nextjs_index lists the tools correctly:

   • get_project_metadata
   • get_errors
   • get_page_metadata
   • get_logs
   • get_server_action_by_id
   • get_routes

   The failure happens when OpenCode tries to call one of those tools through nextjs_call.

   For example, calling the no-arg get_errors tool fails with:

   MCP error -32603: Invalid argument 'args': [
     {
       "code": "invalid_type",
       "expected": "object",
       "received": "string",
       "path": [],
       "message": "Expected object, received string"
     }
   ]
   

   I also tried get_routes with args set to JSON text like this:

   {"routerType":"pages"}

   That fails the same way: the server still receives a string where it expects an object.

   This same Next MCP setup works for me in Cursor, so the Next server and MCP endpoint seem fine. The difference looks like it is in how OpenCode forwards or normalizes the tool arguments. It lines up with Keesan12’s comment above: something appears to stringify the object-shaped argument before it reaches the MCP transport layer.
5. davilima6 commented on Jun 18, 2026

   

   davilima6

   on Jun 18, 2026

   Last edited by davilima6

   More actions

   I proposed a fix in #32812. The Next.js MCP server works as expected with that branch
6. rekram1-node commented on Jun 22, 2026

   

   rekram1-node

   on Jun 22, 2026

   Collaborator

   More actions

   

   this would just be ur model not calling tools correctly rather than an opencode bug, maybe u can share a repro? but i cannot reproduce this
7. rekram1-node

   closed this as not plannedon Jun 22, 2026
8. davilima6 commented on Jun 22, 2026

   

   davilima6

   on Jun 22, 2026

   More actions

   @rekram1-node , thanks for looking into it! I'll try to prepare a separate, throw-away PR with a repro