[BUG] Claude Desktop 1.1.3189 (Cowork) serializes MCP object parameters as strings, breaking Notion MCP writes

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/26027
2. https://github.com/anthropics/claude-code/issues/25865
3. https://github.com/anthropics/claude-code/issues/23500

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Confirming the same issue on the Claude Desktop Mac app (standard mode, not Cowork).

Claude self-diagnosis of the problem:

All Notion MCP read tools (notion-fetch, notion-search) work fine. All write tools (notion-update-page, notion-create-pages) fail silently — no error surfaced to the user, just repeated failures regardless of payload size or format. I tried ~8 different parameter structures before concluding it wasn't a schema issue on my end.

This is blocking a real workflow: I use Claude to maintain structured client documentation in Notion. The read → analyze → write-back loop is broken, so I'm falling back to manual copy-paste from Claude's output.

Environment: Claude Desktop Mac app, Claude Opus 4.6, Notion MCP connected via built-in integration. Writes were working earlier this week.

Seem like It's a problem on all subpages. It's basically impossible to write anything back to Notion. This is a core part of my workflow as well.

Same environment as @AndySparks but verifying it's all models not just Opus 4.6.

I'm seeing the same issue on MacOS with Opus 4.6. Having to use the workaround of creating new pages and moving them myself. It's a shame this has broken as it was a very powerful workflow previously.

One other note on workflows that require writing to notion or page creation - the skill works fine in Claude.ai. The Notion MCP connector bug is Cowork-specific or desktop specific it seems.

thanks for the report+info folks, we've identified the issue and a fix is on the way

adding some additional detail:

Production Impact Report — Cowork Power User

Adding context on the scope of this bug's impact for prioritization purposes.

Use case: I run a daily automated workflow in Cowork that scans ~75 Notion pages (a TV show bible), detects edits and comment threads, and auto-generates changelog entries in a Notion database. It's a scheduled skill that runs every morning — reads via MCP, writes results back to Notion.

What broke: Every write operation fails. notion-create-pages, notion-update-page — all hit the serialization error. Reads are fine, which makes it worse: Claude can see everything, analyze everything, generate all the right data, and then can't write any of it back.

Workaround built: To keep the workflow running, I had to build a Cloudflare Worker + D1 command queue that proxies Notion API calls. Claude inserts commands into a D1 database, a Worker picks them up on a 1-minute cron, and calls the Notion API directly. It works, but it's a proxy layer that shouldn't need to exist.

On its first production run (2026-02-20), the pipeline processed 9 page creates and 2 block updates successfully — so the underlying Notion API is fine, it's purely the client-side serialization that's broken.

Time cost: ~4 hours building and debugging the proxy infrastructure, plus ongoing maintenance overhead on every session that touches Notion.

What would help: Even a rough ETA on the fix would be useful for planning. If it's days, I'll wait. If it's weeks, I'll invest more in hardening the proxy. The "fix is on the way" from Feb 18 is appreciated but ambiguous.

Also noting that the server-side fix in makenotion/notion-mcp-server PR #212 (which handles double-serialized params gracefully) was reopened on Feb 19 and could unblock this independently of a client fix — might be worth coordinating with the Notion team on merging that.

I’m seeing a closely related issue with the Notion MCP notion-update-page tool in Claude Code / Cowork.

In my case, Claude serializes the tool call with a data wrapper, e.g.:

{
"data": {
"page_id": "…",
"command": "update_properties",
"properties": { … }
}
}

But the Notion MCP server responds with:

MCP error -32602: Invalid arguments for tool notion-update-page
[
{
"code": "invalid_type",
"expected": "string",
"received": "undefined",
"path": ["page_id"],
"message": "Required"
}
]

The same page_id and properties work when I call Notion’s REST API directly with PATCH /v1/pages/{page_id}.

This seems to be another manifestation of the MCP object-parameter serialization / schema mismatch described here, but specifically for notion-update-page using a data: { … } wrapper.

@jerome3o-anthropic would we be able to get an ETA on the fix for this please? This is very disruptive to a number of my workflows, so I'm just trying to work out whether to invest more time in alternative solutions, or whether there will be a fix soon.
Thanks in advance!

@jerome3o-anthropic I'm also suffering from big workflow issues due to this issue, any update? @anthropic-xabi @ah-anthropic @km-anthropic ?

Same issue with the Google Workspace MCP connector — modify_gmail_message_labels and batch_modify_gmail_message_labels both fail in Cowork because add_label_ids / remove_label_ids (Optional[List[str]]) arrive as JSON strings instead of parsed arrays.

1 validation error for call[batch_modify_gmail_message_labels]
add_label_ids
  Input should be a valid list [type=list_type, input_value='["Label_1", "Label_67..."]', input_type=str]

Both tools work correctly from Claude.ai Chat with the same connector. Confirms the serialization issue isn't limited to object-typed parameters or Notion — List[str] is affected too.

Firebase MCP: Another instance of the Cowork parameter serialization bug

Adding a detailed data point from the Firebase MCP (firebase-tools built-in MCP server) exhibiting the same symptom pattern described in this issue.

Environment

• Claude Desktop (Cowork mode) on macOS
• MCP config (claude_desktop_config.json):

``json
"firebase": {
"command": "npx",
"args": ["-y", "firebase-tools@latest", "mcp", "--dir", ".", "--only", "functions,firestore"],
}
``

• Firebase project: Active Firestore database, working auth, deployed Cloud Functions
• Date: March 2026

Affected tools

| Tool | Status | Parameter types |
|------|--------|----------------|
| firestore_get_document | ✅ Works | Simple strings (path) |
| firestore_query_collection | ✅ Works | Strings (collection_path, where, order_by, limit) |
| firestore_list_collections | ✅ Works | String (document_path) |
| firestore_list_documents | ✅ Works | String (collection_path) |
| firestore_add_document | ❌ Broken | Object (document field with nested structure) |
| firestore_update_document | ❌ Broken | Object (document field with nested structure) |

Exact error

Invalid value at 'document' (type.googleapis.com/google.firestore.v1.Document)

This is a protobuf type mismatch error from the Firestore REST API, meaning the document parameter arrives as a string instead of a structured object.

Formats tested (all fail)

1. Plain JSON:

{
  "collection_path": "myApp/data/items",
  "document": {
    "title": "Hello",
    "status": "active"
  }
}

2. Firestore REST typed format:

{
  "collection_path": "myApp/data/items",
  "document": {
    "fields": {
      "title": { "stringValue": "Hello" },
      "status": { "stringValue": "active" }
    }
  }
}

3. With explicit name field:

{
  "collection_path": "myApp/data/items",
  "document": {
    "name": "projects/my-project/databases/(default)/documents/myApp/data/items/test",
    "fields": {
      "title": { "stringValue": "Hello" }
    }
  }
}

All three produce the identical protobuf type error.

Key evidence: Works in Claude Code, broken in Cowork

The exact same Firebase MCP works perfectly in Claude Code (terminal CLI) when installed via the plugin marketplace:

claude plugin marketplace add firebase/firebase-tools
claude plugin install firebase@firebase

In Claude Code, firestore_add_document and firestore_update_document execute without issues. The MCP server binary is identical. The only difference is the transport layer:

• Claude Code: Direct stdio connection to MCP server → works
• Claude Desktop / Cowork: Proxied through OneMcpServer in the Cowork VM → broken

Root cause hypothesis

This is consistent with the double-serialization bug described in this issue and in #26027. The Cowork VM proxy layer serializes object parameters as JSON strings before passing them to the MCP server. For tools where all parameters are simple strings (like firestore_get_document(path="...")) this is invisible. But for tools with structured object parameters (like firestore_add_document(document={...})), the object becomes "{\"fields\": ...}" (a JSON string) instead of {fields: ...} (a native object), causing the downstream protobuf deserialization to fail.

This is the same pattern reported with the Notion MCP and other connectors: reads work, writes fail, because reads tend to accept string identifiers while writes require structured payloads.

Been hitting this in the last days. Big blocker interacting with my Home Assistant MCP server.

Still reproducible on Claude Desktop (macOS) 1.26832.0, local agent mode, 2026-08-11 — and it looks like a fresh regression rather than the February one: identical calls worked on 2026-08-08 and broke by 2026-08-11 with the app binary unchanged since Aug 6, so the moving part seems to be the bundled agent runtime or the connector proxy, not the app itself.

Symptoms match this thread exactly: object/array parameters to claude.ai connectors arrive as JSON-encoded strings; scalar parameters bind fine.

Measured on three independent servers the same day (while operating the WordPress/SEO connectors behind https://unicorgi.dk):

• Go-based server (Semrush connector): params: {"target": "…", "database": "dk"} → json: cannot unmarshal string into Go struct field ExecuteReportRequest.params of type map[string]interface {}
• WordPress server: fields: ["name"] arrives as the literal string ["name"] — the server rejects input[fields][0], i.e. index 0 is the character [
• Morningscore server: object params (pagination, sort) are silently ignored, so every page request returns page 1

Two details that may help debugging:

1. A server that json-decodes string inputs still works — the value arrives as a decodable JSON string, not garbage.
2. A brand-new subagent context reproduces it on the first call, so it is not conversation state.