There's a tax we've all paid for so long that we stopped noticing it: the app switch. Copy from the meeting notes, alt-tab, paste into the task tracker, reformat, alt-tab, update the doc, alt-tab back to see what you missed. Researchers call it context-switching cost. I call it Tuesday.
The Model Context Protocol — MCP — is the first thing I've used that attacks this tax at the root instead of the symptoms. And Notion's MCP server is where it clicked for me.
USB-C for software
Before USB-C, every device shipped its own cable, and your drawer was a museum of adapters. Before MCP, every AI integration was a bespoke plugin: one for Notion, one for Jira, one for your calendar, each with its own auth dance and its own half-maintained API wrapper.
MCP standardizes the port. An AI assistant that speaks MCP can connect to any tool that exposes an MCP server — read from it, write to it, search it — through one protocol. Notion publishes the server; my assistant plugs in; the drawer of adapters goes in the bin.
What it actually looks like
A concrete morning from last week. I finished a design review call with messy notes in Notion. One request to my assistant:
"Read today's review notes, turn the action items into tasks in the sprint database, and draft a summary page for stakeholders."
It fetched the page over MCP, created the database entries with the right properties, and drafted the summary — in my workspace, in my templates, with my naming conventions. Total elapsed time: the length of a coffee refill. The old version of that workflow had eleven app switches in it. I counted once, out of spite.
The detail that won me over is that nothing about Notion had to change for this to work. The workspace I've curated for years became programmable overnight, simply because the door got standardized.
The design implication: the UI is no longer the only door
Here's where my designer brain starts buzzing. For my whole career, the interface was the product. If a capability wasn't reachable through a screen, it didn't exist. MCP breaks that assumption: now an app's capabilities can be exercised by an agent acting on a user's intent, without the user ever seeing the app's chrome.
Some designers hear that as a threat. I hear a promotion. It means we're no longer just designing screens — we're designing capabilities and their contracts:
- Naming becomes interface. When an agent picks which tool to call, the tool's name and description are its signage. Information architecture just escaped the sidebar.
- Defaults become policy. What an MCP action does when a property is unspecified is a design decision with real consequences. Someone thoughtful should be making it.
- Error states grow up. "Something went wrong" is unacceptable when the reader is an agent that could recover, retry, or ask — if only the error explained itself.
The optimistic ending
I don't believe app UIs are dying — when I'm thinking in Notion, arranging blocks by hand, the canvas is irreplaceable. What's dying is the app as a silo: the idea that your data's usefulness ends at the edge of one company's window.
The web got good when links made pages composable. Tools are about to get good the same way, because MCP makes capabilities composable. We spent twenty years gluing our workflows together by hand, with clipboard and patience. The glue is finally becoming infrastructure — and the people who design that infrastructure thoughtfully are going to define how the next decade of work feels.
I'd like to be one of them. The alt-tab key deserves the retirement.