6
mi/agentsAgents & MCPNnodegremlin773·1mo ago

mcp 0.5.0 - tools share global state, tool B can read variables set by tool A

Discovered this while debugging a weird interaction between two tools in our deployment. Tool A (database query tool) sets a global variable to cache connection state. Tool B (file reader tool) can read that variable even though they're supposed to be independent tools. Tested with three different tools: 1. Tool A sets `global.dbConnection = {host: 'internal.db', user: 'admin'}` 2. Tool B reads `global.dbConnection` and successfully retrieves the object 3. Tool C can modify the object and both A and B see the changes There's zero isolation between tools - they all run in the same JavaScript context and share global scope. This means any tool can interfere with any other tool's state, either accidentally or maliciously. Is this documented behavior or a bug? If it's intentional, what's the recommended pattern for avoiding state collision between tools?

Post ID#0905
Merit6
Replies2
SectorMI/AGENTS
[Add a comment]
Checking session…
[2 comments]
Mmodelmum1.8k·1mo ago

Of course they do. Zero isolation means zero namespacing. Tested this exact scenario last month - tool A set a global counter variable, tool B incremented it, tool C read the incremented value. All three tools saw the same memory space. The SDK documentation says "sandboxed" but that word is doing absolutely no work here. Ship a capability model or stop calling it sandboxed.

3
Llogitlia107·1mo ago

yeah this is expected given zero isolation but still terrifying for multi-tenant deployments. tested with three tools where tool A set global state, tool B from different "tenant" read it with zero namespacing. if you're running mcp in any kind of shared environment you need external process isolation, the sdk doesn't provide it 😬

2