BUG MCP PLUGINS behavior fails
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Summary
Inside a Cowork artifact, calling an MCP tool that belongs to a plugin-bundled MCP server (one
declared in a plugin's .mcp.json, launched as a local npx/stdio process) consistently fails with a
generic Tool call failed: 400 — even when the identical tool, called with identical arguments, succeeds
reliably when invoked directly by Claude outside the artifact in the same session. In contrast, a
connector-style MCP tool (e.g. a first-party Gmail connector) called from inside the same artifact,
in the same session, succeeds immediately. This points to a restriction specific to how Cowork artifacts
reach plugin-bundled MCP servers, not a general connectivity or session problem.
Environment
Product: Claude Desktop, Cowork mode
Plugin: atomic47-crm (private, org-restricted marketplace plugin), bundling MongoDB's official
mongodb-mcp-server via npx -y mongodb-mcp-server@latest, stdio transport, configured via
MDB_MCP_CONNECTION_STRING in the plugin's .mcp.json
The plugin's MCP server tools are namespaced mcp__plugin_atomic47-crm_atomic47-crm-db__<tool>
The connector used for comparison is a first-party Gmail connector, namespaced
mcp__<installation-hash>__<tool>
Steps to reproduce
From a Cowork session with the atomic47-crm plugin installed and its MongoDB MCP server connected,
confirm a plugin-bundled tool works when called directly (not from an artifact) — e.g.
mcp__plugin_atomic47-crm_atomic47-crm-db__aggregate against a real collection. This succeeds
reliably and returns real data.
Build a Cowork artifact (mcp__cowork__create_artifact) whose HTML calls the same tool via
window.cowork.callMcpTool('mcp__plugin_atomic47-crm_atomic47-crm-db__aggregate', {...}), with the
exact same arguments used in step 1.
Open/verify the artifact (mcp__cowork__verify_artifact) and inspect its debug log.
In the same artifact, also call a connector-style tool available in the session, e.g.
window.cowork.callMcpTool('mcp__<gmail-connector-hash>__list_labels', {}).
Expected behavior
Both calls succeed and return data, matching what happens when the same tools are called directly
outside the artifact.
Actual behavior
The plugin-bundled tool call (mcp__plugin_atomic47-crm_atomic47-crm-db__aggregate) fails every time
with a bare Tool call failed: 400 — no further detail in the artifact debug log. This was reproduced
across multiple artifact rebuilds, multiple argument variations, and after explicitly calling the
plugin's own connect tool first (also namespaced mcp__plugin_atomic47-crm_atomic47-crm-db__connect,
which also fails with the same 400 from inside the artifact, despite succeeding when called directly).
The connector-style tool call (mcp__<gmail-connector-hash>__list_labels), made moments later in the
same artifact, in the same session, succeeds immediately (isError: false, real data returned).
Debug log excerpt (from mcp__cowork__verify_artifact)
{"kind":"callMcpTool","tool":"mcp__plugin_atomic47-crm_atomic47-crm-db__aggregate", ...,
"isError":true,"resultPreview":"[content,isError]→Tool call failed: 400 "}
{"kind":"callMcpTool","tool":"mcp__plugin_atomic47-crm_atomic47-crm-db__connect", ...,
"isError":true,"resultPreview":"[content,isError]→Tool call failed: 400 "}
{"kind":"callMcpTool","tool":"mcp__<gmail-connector-hash>__list_labels","argsPreview":"{}",
"isError":false,"resultPreview":"[content,structuredContent,isError]→{}\n"}
Why this looks like a platform restriction, not a plugin bug
The exact same plugin-bundled tool, with the exact same arguments, called directly by Claude (outside
any artifact) in the same session succeeds reliably every time.
A connector-style tool, called from inside the same artifact sandbox, succeeds immediately.
The failure is a generic transport-level 400, not a data-layer or connection-string error (which,
called directly, returns a specific, descriptive error message instead).
This suggests Cowork artifacts may only be able to reach a specific class of MCP servers (e.g. first-party
or remote/HTTP-based connectors) and not locally-spawned, plugin-bundled MCP servers — which would mean
any plugin that bundles its own MCP server (not just this one) cannot build a working live-data
artifact today, regardless of how correct the artifact's own code is.
Possibly related, not yet confirmed connected
Separately (same project, same general area), we've also hit:
anthropics/claude-code#39455 / #39827 — plugin userConfig prompt doesn't fire on enable
anthropics/claude-code#39125 — Cowork sessions don't inject user_config values into a
plugin-bundled MCP server's environment
These may or may not share a root cause with the artifact issue above, but all three point in the same
general direction: Cowork's handling of plugin-bundled MCP servers (as opposed to connectors) appears to
be less complete/reliable than connector handling. Flagging the possible connection in case it's useful
context for triage, without asserting they're the same bug.
Impact
Any Claude plugin that (a) bundles its own MCP server and (b) wants to build a Cowork artifact that reads
live data from that server is currently blocked, as far as we can tell, regardless of the artifact's own
code being correct. We worked around it in our own plugin (atomic47-crm 0.6.0) by having the artifact
fetch data outside itself and bake a static snapshot in, rather than fetching live from inside the
artifact — but this is a workaround, not a fix, and loses the "always current on reopen" property a live
artifact would have.
Reporter
Fulvio Ciano ([fulvio@atomic47.co](mailto:fulvio@atomic47.co)), Atomic 47 Labs
What Should Happen?
see above
Error Messages/Logs
{"kind":"callMcpTool","tool":"mcp__plugin_atomic47-crm_atomic47-crm-db__aggregate", ...,
"isError":true,"resultPreview":"[content,isError]→Tool call failed: 400 "}
{"kind":"callMcpTool","tool":"mcp__plugin_atomic47-crm_atomic47-crm-db__connect", ...,
"isError":true,"resultPreview":"[content,isError]→Tool call failed: 400 "}
{"kind":"callMcpTool","tool":"mcp__<gmail-connector-hash>__list_labels","argsPreview":"{}",
"isError":false,"resultPreview":"[content,structuredContent,isError]→{}\n"}Steps to Reproduce
- From a Cowork session with the atomic47-crm plugin installed and its MongoDB MCP server connected,
confirm a plugin-bundled tool works when called directly (not from an artifact) — e.g.
mcp__plugin_atomic47-crm_atomic47-crm-db__aggregate against a real collection. This succeeds
reliably and returns real data.
- Build a Cowork artifact (mcp__cowork__create_artifact) whose HTML calls the same tool via
window.cowork.callMcpTool('mcp__plugin_atomic47-crm_atomic47-crm-db__aggregate', {...}), with the
exact same arguments used in step 1.
- Open/verify the artifact (mcp__cowork__verify_artifact) and inspect its debug log.
- In the same artifact, also call a connector-style tool available in the session, e.g.
window.cowork.callMcpTool('mcp__<gmail-connector-hash>__list_labels', {}).
Claude Model
Sonnet (default)
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
1.21459.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_