Model Context Protocol Explained for Designers and PMs
Someone on your engineering team said "we're adding an MCP server for that" in standup, and you nodded like you understood. You didn't, and that's fine, because most of what gets written about MCP is written by developers, for developers, full of JSON snippets and SDK references that tell you nothing about what it means for your product.
Here's the plain version: Model Context Protocol is quietly becoming the wiring standard for how AI agents connect to the rest of the software you already use. If you're a PM scoping an agentic feature or a designer trying to figure out what's actually possible, you need the concept, not the code.
What MCP Actually Is
Think about USB-C for a second. Before it existed, every device had its own charging cable, its own port shape, its own adapter. Then one standard showed up and suddenly your laptop, phone, and headphones all plugged into the same kind of port. MCP is that idea applied to AI.
Before MCP, if you wanted an AI model to read your company's Notion docs, check Slack, and create a Jira ticket, someone had to build three separate custom integrations, each with its own authentication, its own data format, its own maintenance burden. Multiply that across every tool and every AI product your company ships, and you get a combinatorial mess: N tools times M AI products equals N times M custom connectors, each one fragile and none of them reusable.
MCP replaces that mess with three defined roles. The Host is the application the user actually sees, something like Claude Desktop, an IDE, or a custom agent your team built. The Client lives inside the Host and manages the connection to one specific server. The Server is the external program, maybe a Slack integration or a database connector, that exposes what it can do in a standard format the model understands.
Once a server speaks MCP, any MCP-compatible host can use it without custom code. Your Slack connector doesn't need to be rebuilt every time a new AI tool wants to talk to Slack. It just needs to speak the protocol once.
The Three Things a Server Can Actually Offer
This is the part that matters most for product thinking, because it defines the shape of what your agent can do.
A server exposes three kinds of capability. Tools are actions the model can take: send a message, create a record, run a query, book a meeting. These are the things that make an agent feel like it's actually doing work instead of just talking about it. Resources are data the model can pull in as context: a file, a customer record, a document, a support ticket. This is how an agent grounds its answers in your actual company data instead of guessing. Prompts are reusable templates the server provides, a standardized way of telling the model "when someone asks about refunds, approach it this way." This is less visible to users but it's how organizations bake their own playbooks into how an agent behaves.
When you're scoping a feature and an engineer says "we can expose that as an MCP tool," what they mean is: the model will be able to actually perform that action, not just describe it. That distinction should change how you write the spec. A chatbot that can tell you your order status is a resource problem. A chatbot that can cancel your order is a tool problem, and it needs a completely different level of confirmation UX, error handling, and audit logging.
Why This Is Showing Up on Your Roadmap Whether You Asked For It Or Not
MCP isn't a niche developer preference anymore. Since Anthropic introduced it in late 2024, the ecosystem has grown at a pace that's genuinely unusual even by AI standards. By March 2026, the protocol was seeing roughly 97 million monthly SDK downloads, a 970x increase in about 18 months, with the official MCP registry tracking more than 9,600 active servers. Fortune 500 enterprise adoption has reportedly reached around 28% in under two years, and analysts estimate close to a third of enterprise application vendors will ship their own MCP server sometime in 2026.
More concretely, the tools your company probably already uses have first-party MCP servers now. Slack's server lets an agent search threads and post updates. GitHub's official server lets an agent read repos, open issues, and submit pull requests. Notion shipped a server that lets an agent read, write, and search across your workspace. Zapier's MCP server acts as a bridge to thousands of other apps, so instead of waiting for a native integration, a team can often get "close enough" connectivity immediately.
For product teams, this changes the build-versus-connect calculus. A feature that once required a dedicated integration sprint might now be a matter of wiring up an existing MCP server. That's good news for velocity. It also means the differentiation in your product is shifting away from "we connected to Salesforce" (increasingly commoditized) toward how well you design the experience around what the agent does with that connection: the confirmations, the context it shows, the way it recovers when something goes wrong.
The Questions You Should Be Asking Before You Ship
Here's the part that doesn't show up in the marketing copy. MCP servers are, by design, giving a model the ability to take real actions and pull in real data, and that creates a genuinely new risk surface that product and design decisions directly affect.
Security researchers have flagged a handful of specific concerns worth knowing the names of, even if you're not the one fixing them. Over-privileged access happens when an agent is connected to a server with far broader permissions than the task requires, the equivalent of giving an intern the admin password because it was easier than setting up a limited account. Tool poisoning is when an attacker manipulates a tool's description or metadata to smuggle in hidden instructions the model might follow without the user ever seeing them. One analysis of open-source MCP servers found roughly 5.5% exhibited these kinds of attack patterns. Indirect prompt injection, where malicious instructions arrive embedded in a document or webpage the agent reads rather than in the user's own request, remains, in the words of one well-known security researcher, an issue the industry has known about for years without a convincing fix.
The 2026 update to the MCP spec introduced incremental scope consent, meaning a client can request only the minimum access needed for a specific operation rather than a blanket grant upfront. That's an engineering fix, but it's also a design opportunity. If your product asks a user to authorize "full calendar access" once during onboarding and never mentions it again, you've built the fragile version. If it asks, in context, "this agent wants to create one event on your calendar, allow it?" every time the stakes go up, you've built the version that survives an incident without losing user trust.
As a PM or designer, you don't need to architect the permission system. You do need to ask your engineering team, explicitly, what scope of access every MCP server connection actually grants, and whether the user has any visibility into that scope at all. That question alone puts you ahead of most teams shipping agentic features right now.
Where This Leaves You
MCP is infrastructure, and infrastructure is usually invisible until it breaks or until it unlocks something your competitors ship faster than you do. Understanding it at the level covered here, host, client, server, tools versus resources versus prompts, and the consent questions that come with real action-taking agents, is enough to sit in a planning meeting and ask the right questions instead of nodding along.
The teams that win the next round of agentic product design won't be the ones who understand the JSON-RPC handshake. They'll be the ones who understood early that a "tool" is a real action with real consequences, and designed the experience around that fact instead of discovering it after launch.
👨💻 Connect With Me
Rohit Raghuvansh
💡 UX Thinker · AI Builder · Making complex tech human-centered
Connect & Follow
📢 Found This Article Helpful?
If this article added value to your learning journey:
✅ Share it with your network ✅ Bookmark it for future reference ✅ Follow for more
Keep Learning. Keep Building. Keep Growing. 🚀
Top comments (0)