{"slug": "mcp-is-not-a-workspace", "title": "MCP Is Not a Workspace", "summary": "MCP gives agents access to every tool but does not connect the work, preserve what sessions learn, or give humans and agents a shared workspace, according to an analysis by the author. The five things a workspace still has to do are bring the work together, remember how the pieces are connected, keep context from getting expensive, carry what one session learned into the next, and give one place to review what the agent did.", "body_md": "# MCP Is Not a Workspace\n\nMCP gives agents access to every tool. It does not connect the work, preserve what sessions learn, or give humans and agents a shared workspace.\n\nYour main workspace has shifted. Your primary home is now wherever you chat with your coding agents and manage their sessions: the CLI, the Codex app, Cowork, VS Code or Cursor, or perhaps a dedicated session manager like Conductor.\n\nBut the rest of your work has not followed. Your tasks are in Linear, docs in Google Docs, diagrams in Miro, mockups in Figma, and conversations in Slack. You connect your agents to all of them through MCP.\n\nMCP is marvelous, but it is not enough. It gets the agent through the door. It does not bring the work together, remember how the pieces are connected, keep all that context from getting expensive, carry what one session learned into the next, or give you one place to review what the agent did. Those are the five things a workspace still has to do.\n\n## Access is not a workspace\n\nEach MCP server opens a door into a different system, but those systems still have their own data models, IDs, search behavior, and ideas about what belongs together. The agent can move among them, but the relationships across them are usually not recorded anywhere.\n\nIf a decision in a Google Doc became a Linear issue, was discussed in Slack, implemented during a coding session, and clarified with a Figma mockup, the agent has no reliable way to know that chain exists unless someone tells it. It can search for the pieces and try to reconstruct the relationship, often successfully, but it is reconstructing it again every time.\n\nA workspace stores that relationship as part of the work itself.\n\n| An agent reaching separate tools over MCP | Work living in a shared workspace |\n|---|---|\n| The agent can open each app | The related work is already together |\n| Connections are inferred during a session | Connections are saved as links |\n| Each system keeps its own IDs and structure | Related artifacts share one navigable context |\n| Cross-tool questions require several searches and a manual join | Linked work can be read together |\n| The next session has to reconstruct the same background | The relationships remain after the session |\n| Results are spread across the original apps | The human and the agent can review them in one place |\n\nYou run into that difference in five ways: your work is still spread across separate systems, the links between it are not saved, your agent has to load too much context, what it learns disappears with the session, and you still have to open every app yourself.\n\n## The connections between things are never stored\n\nSay you are looking at a line of code and want to know why it exists. The answer may begin in a product decision, continue through a task and a Slack thread, and end in the session that changed the file. The useful context is the path that runs through all of them.\n\nWith separate MCP connections, the artifacts are available but the path is not. A Linear issue does not naturally know which paragraph in a Google Doc created it. A Slack thread does not necessarily point to the commit that resolved it. The agent can follow names, keywords, timestamps, and whatever links people happened to paste, but every step adds another search and another judgment about whether it found the right thing.\n\nThat leaves a person as the system of record for how the work fits together. Someone has to remember the connections, paste the links into the right places, and update them when anything changes. You can ask the agent to do this, but it still has to decide where each link belongs and write it into several unrelated systems. The Linear issue might link to the Google Doc while the doc still links to an old issue and the Slack thread links to neither. Nothing owns the relationship, so it drifts.\n\nThis does not mean an agent cannot reason across apps. It can, and sometimes it does it remarkably well. The catch is that the result of that reasoning normally lives only in the current context window. The next agent has to do the work again.\n\nIn a workspace, the links themselves can be saved. A tracker item can point to the doc that explains it. A session can link to the files it changed and the task it addressed. A diagram can sit beside the plan that references it. A question like “Why was this built, and what has touched it since?” becomes a walk through known relationships instead of a fresh investigation across several systems.\n\nDepth comes from reliable connections: the agent has to find all the pieces and know which ones actually belong to one another.\n\n## Disconnected context gets expensive\n\nMCP can add to token cost before the agent has done any useful work. If every connected tool schema is loaded eagerly, the descriptions alone can reach roughly 280,000 tokens. This is why newer agent harnesses increasingly search for tools and load only the relevant schemas when they are needed.\n\nThe larger cost comes from using the tools. A detailed Linear issue, a noisy Slack search, and a full Google Doc all enter a context window that may already be large. They often stay there for the rest of the session, even if the agent needed only a small part of each. A new session may retrieve the same material again because the connection the previous session discovered was never saved.\n\nTo measure the difference, one ordinary cross-tool question, “What is the status of the auth work and what is left?”, was answered two ways: by reading from the connected apps over MCP, and from a single pre-joined read in the workspace. Both were tokenized with an off-the-shelf tokenizer that runs a little under Claude’s own, so the figures are conservative.\n\n| To answer one cross-tool question | Tokens vs one workspace read |\n|---|---|\n| Slack, GitHub, Linear | ~12x |\n| plus Google Docs | ~30x |\n| plus Figma | ~40x |\n\nText tools were the cheap tier, and most of their cost was the tool schema loaded before any question was asked. Google Docs roughly tripled the payload with one pull of the relevant documents. Figma was the heavy addition: a single design read was roughly 20,000 tokens, since design tools return whole node trees even after the MCP simplifies them. The same design, kept in the workspace as a local mockup, was about a fifth of that.\n\nA workspace does not make context free. You still pay the same underlying cost for the model to do the work. What changes is how much background has to be rebuilt. If the task, decision, session, diagram, and affected files are already linked, the agent can start from that smaller set of relevant material instead of searching several systems and assembling the story inside its context window.\n\nOne search across several apps may not look expensive. Repeating some version of it over 41 turns, then doing it again in the next session, is where it starts to matter.\n\n## Understanding should survive the session\n\nThe bigger issue goes beyond token cost: what your agent understands during a session rarely becomes part of your team’s shared knowledge.\n\nIn a collection of separate tools, the way the work fits together tends to live in one of two places: in a person’s memory, or in the temporary reasoning an agent performs while answering a question. A person may remember that the Slack thread, the doc, and the task are related, but the system has not learned that. An agent may reconstruct the full history beautifully, but unless someone records the result, the next session starts with the same disconnected pieces.\n\nThis is the difference between storing documents and storing understanding. The documents can be perfectly durable while the relationships between them stay informal and fragile.\n\nMCP gives an agent access to the places where work happens. A workspace records how that work fits together, so the understanding can be shared, corrected, and reused after the session ends.\n\nThe record gets more useful over time. Each linked task, decision, file, session, and diagram gives the next person or agent a better starting point. Everything was already searchable. Your team no longer has to keep rediscovering the same structure.\n\n## The agent can reach everything, but you still have to visit it\n\nThere is also a more ordinary problem: MCP reduces the agent’s context switching, but not yours.\n\nWhen the agent updates the Linear issue, edits the Google Doc, adds a note in Obsidian, and replies in Slack, the work is still spread across those four places. To review what happened, you have to open them. In many cases that is exactly right (GitHub should stay the canonical home for code, for example), but connecting the apps does not create a shared surface for the person supervising the work.\n\nYou need the agent’s output to land somewhere you can see it, edit it, and connect it to the next piece of work. Your edits should be immediately available to the agent without being copied back into a prompt. You need a surface where you and the agent are actually working together, not just access to a set of private app schemas.\n\nThis is the part you notice every day. The agent has an easier way to move through your tools while you are still making the same tour of tabs.\n\n## MCP is still the right tool for reach\n\nNone of this is an argument against MCP. Nimbalyst supports it, and it remains the right tool for reaching external systems.\n\nMCP is especially valuable for systems that cannot or should not move into a workspace: a company’s Salesforce account, a production database, GitHub as the canonical home for code. There the goal is access, and MCP gives the agent a consistent way to get it.\n\nMCP and a workspace are different layers of the same system. MCP is how the agent reaches an external tool. The workspace is where the working context lives, where the relationships are stored, and where a person can understand and change what the agent is doing. They work well together, and one does not replace the other.\n\nYou can give an agent access to every system your company uses and still have no shared model of the work that crosses them.\n\n## Where Nimbalyst fits\n\nNimbalyst is built to provide that shared model. Sessions and prompts, tasks, docs, notes, diagrams, mockups, diffs, and code can live in one visual workspace and link to one another directly. The agent can still reach out over MCP to systems that need to stay elsewhere, but the working context no longer has to be reconstructed from those systems every time.\n\nThe aim is to give the work itself a home, not to pull every tool into a new container. It should be a place where the relationship between a decision, a task, a conversation, and the resulting change stays visible after the session is over.\n\nNimbalyst is open source, and its individual-use features are MIT licensed. If you have connected an agent to a drawer full of MCP servers and the result still feels oddly fragmented, this is probably the difference you are hitting. The agent can reach the work, but the work still does not live together.\n\n## Related pages\n\n-\n### What Is an Agent Harness?\n\nThe eight layers around an AI agent, and the failure mode each one answers.\n\n-\n### Best MCP Clients in 2026\n\nA comparison of desktop clients, IDEs, coding agents, and shared agent workspaces.\n\n-\n### Why Nimbalyst\n\nSee what a visual workspace adds around Codex, Claude Code, and other coding agents.\n\n## Related posts\n\n-\n### Why we put Obsidian, Linear, Terminal, Codex app, and Conductor in one workspace\n\nPlans, diagrams, tasks, agent sessions, and diff review used to live in five apps. Putting them in one workspace changes how agentic engineering feels.\n\n-\n### Open sourcing Nimbalyst: the visual workspace for building with Codex, Claude Code, and more\n\nToday we are open-sourcing Nimbalyst, the visual workspace for building with Codex, Claude Code, and more. Free for individual use, MIT licensed desktop app.\n\n-\n### Best MCP Servers for Claude Code in 2026 (Ranked and Tested)\n\nThe best MCP servers for Claude Code in 2026, ranked and tested: GitHub, Context7, Playwright, Postgres, Exa, and the essential picks, with install commands and the context-cost tradeoffs of running many at once.", "url": "https://wpnews.pro/news/mcp-is-not-a-workspace", "canonical_source": "https://nimbalyst.com/blog/mcp-is-not-a-workspace/", "published_at": "2026-07-29 00:00:00+00:00", "updated_at": "2026-07-29 21:57:08.566193+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools"], "entities": ["MCP", "Linear", "Google Docs", "Miro", "Figma", "Slack", "Codex", "Conductor"], "alternates": {"html": "https://wpnews.pro/news/mcp-is-not-a-workspace", "markdown": "https://wpnews.pro/news/mcp-is-not-a-workspace.md", "text": "https://wpnews.pro/news/mcp-is-not-a-workspace.txt", "jsonld": "https://wpnews.pro/news/mcp-is-not-a-workspace.jsonld"}}