[BUG] mimo-v2.5-pro serializes oneOf tool call parameters as strings instead of objects

[nicklam1994]

Description

mimo-v2.5-pro serializes complex oneOf (discriminated union) tool call parameters as JSON strings instead of nested objects, causing MCP server validation failures.

This is a model behavior difference — mimo-v2.5 and deepseek-v4-pro handle the same schema correctly.

Environment

Item	Value
Model	mimo-v2.5-pro (via token-plan-cn.xiaomimimo.com/v1)
Control models	mimo-v2.5 ✅, deepseek-v4-pro ✅
Agent framework	Hermes Agent v0.15.1 (OpenAI SDK 2.24.0)
MCP server	obsidian-mcp-server 3.1.5
MCP protocol	stdio

Tool Schema (simplified)

{
  "name": "obsidian_get_note",
  "parameters": {
    "type": "object",
    "properties": {
      "format": {"type": "string"},
      "target": {
        "oneOf": [
          {
            "type": "object",
            "properties": {
              "type": {"const": "path"},
              "path": {"type": "string", "minLength": 1}
            },
            "required": ["type", "path"]
          },
          {
            "type": "object",
            "properties": {
              "type": {"const": "active"}
            }
          }
        ]
      }
    }
  }
}

Expected Behavior (mimo-v2.5 / deepseek-v4-pro)

Model generates tool call with target as a nested object:

{
  "format": "content",
  "target": {
    "type": "path",
    "path": "01-Projects/notes.md"
  }
}

MCP server receives object → validation passes ✅

Actual Behavior (mimo-v2.5-pro)

Model generates tool call with target as a JSON string:

{
  "format": "content",
  "target": "{\"type\":\"path\",\"path\":\"01-Projects/notes.md\"}"
}

MCP server receives string → validation fails ❌

Invalid arguments for tool obsidian_get_note: [
  {
    "code": "invalid_type",
    "expected": "object",
    "path": ["target"],
    "message": "Invalid input: expected object, received string"
  }
]

Reproduction Steps

1. Use OpenAI-compatible API with mimo-v2.5-pro
2. Provide a tool whose parameter schema uses oneOf (discriminated union)
3. Model generates the tool call — oneOf parameters are serialized as strings

Comparative Test Results

Model	target serialization	Result
mimo-v2.5	{"type":"path","path":"..."} (correct object)	✅ Pass
mimo-v2.5-pro	"{\"type\":\"path\",\"path\":\"...\"}" (string)	❌ Fail
deepseek-v4-pro	{"type":"path","path":"..."} (correct object)	✅ Pass

All three models use the exact same tool definitions, agent framework, and MCP server.

Impact

Any agent framework using MCP (Model Context Protocol) tools with oneOf schema parameters will break when using mimo-v2.5-pro. This affects:

• Obsidian MCP tools (target parameter)
• Any custom MCP server with discriminated union parameters
• Claude Code, Cursor, and other agent tools that pass complex schemas

Suggested Fix

During tool call generation, validate that parameter values match the declared JSON Schema types. For type: "object" parameters, ensure output is a JSON object, not a stringified JSON.

Related

• MiMo API rejects OpenAI-compatible tool calling messages in conversation history (400 Param Incorrect) #44 — MiMo API rejects OpenAI-compatible tool calling messages
• [BUG] Claude Code API Error: 400 messages[1].role must be either 'user' or 'assistant', but got 'system' #54 — Claude Code API Error with mimo-v2.5-pro

Workaround

Use mimo-v2.5 (non-Pro) or deepseek-v4-pro for tool-calling workloads.

[nicklam1994]

Update (2026-06-04)

Tested mimo-v2.5 (non-Pro) via Hermes Agent and it also fails with the same oneOf serialization bug.

Reproduction

Tool	Schema	mimo-v2.5 result
obsidian_get_note	target: oneOf [path, active, periodic]	❌ "expected object, received string"
obsidian_append_to_note	target: oneOf	❌ same error
obsidian_manage_frontmatter	target: oneOf	❌ same error
obsidian_manage_tags	target: oneOf	❌ same error
obsidian_list_notes	no oneOf params	✅ works
obsidian_search_notes	no oneOf params	✅ works
obsidian_list_tags	no params	✅ works

Conclusion

Both mimo-v2.5 and mimo-v2.5-pro are affected. Only DeepSeek v4 serializes oneOf correctly.

This means the earlier comparison table in this issue (showing mimo-v2.5 as ✅ Pass) may need to be updated — either the test was done with a different model version, or there is a regression since the original filing.