DEV Community: rohit raghuvansh

Model Context Protocol Explained for Designers and PMs

rohit raghuvansh — Mon, 06 Jul 2026 04:11:03 +0000

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

LinkedIn — Rohit Raghuvansh

📢 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. 🚀

The UX of AI Agents: Designing for Autonomy and Trust

rohit raghuvansh — Mon, 29 Jun 2026 10:11:54 +0000

The UX of AI Agents: Designing for Autonomy and Trust

Your agent works perfectly in the demo. Your users still don't trust it. Here's why, and what to actually do about it.

The question used to be "can AI do this?" In 2026, that question is largely settled. The harder question now is: "Can I trust AI to do this for me, without watching every step?"

Gartner projects that 40% of enterprise applications will embed task-specific AI agents by end of 2026, up from under 5% in 2025. That's a massive wave of agentic products about to land on real users. Most of them will fail the trust test, not the capability test.

This is a UX problem. And it's yours to solve.

Why AI Agents Break Traditional UX Assumptions

Traditional software does what you tell it, when you tell it. The user is always in control. The feedback loop is instant: click, then result.

AI agents operate on a completely different contract. You describe what you want, and the agent decides how to get there, taking multiple steps, using multiple tools, making micro-decisions you never explicitly authorised. The result might arrive 30 seconds later, or 5 minutes later, after a chain of actions the user never saw.

This breaks three UX assumptions that designers have relied on for decades.

Predictability breaks. Users can't anticipate what the agent will do next, because the agent is making judgment calls.

Reversibility breaks. Some agent actions like sending an email, booking a meeting, or submitting a form can't be undone. The stakes of a misstep are real.

Visibility breaks. The traditional feedback loop is gone. The agent works in the background, and silence feels like nothing happening.

When these three assumptions break, trust breaks too. And unlike a slow-loading page, a trust deficit is very hard to recover from.

Transparency Is a Design Surface, Not a Setting

The instinct of most teams is to hide complexity. Clean UI, minimal chrome, just show the output. This is exactly wrong for agentic products.

The "black box launch" is one of the most common failure patterns in agentic UX. A team ships an agent with a polished interface that shows inputs and outputs but nothing in between. Users see a spinner, then a result. They have no idea what happened. Because they don't know what happened, they can't verify the result. Because they can't verify it, they don't trust it.

What to build instead:

Reasoning panels are collapsible sidebars or inline sections showing the agent's step-by-step actions in plain English. Not a raw log. Something like: "Searched your emails for invoices from March, found 3 matching, summarised totals." Users rarely read this in detail, but knowing it exists dramatically increases confidence.

Action cards surface a brief confirmation before the agent executes anything consequential: "I'm about to send this email to your manager. Confirm or edit?" This single intervention point removes most of the fear associated with autonomous actions.

Confidence signals tell the truth about uncertainty. "I found 2 possible matches. Here's the one I think you meant, but check the other if this looks wrong." Uncertainty expressed honestly builds more trust than false confidence.

The key insight: transparency is not a feature you add at the end. It is a design surface you plan from the beginning, the same way you plan navigation or error states.

Control Surfaces: Give Users the Wheel Even When They Don't Need It

There's a real paradox in agentic UX. Users want agents to work autonomously, but they also want to feel in control. The trick is designing control surfaces that exist without interrupting.

Progressive autonomy is the most effective pattern here. Start the agent in supervised mode, where every significant action requires a quick confirmation. As the user sees the agent make good decisions consistently, let them unlock more autonomy. The agent now acts without asking for low-stakes tasks, but still surfaces high-stakes ones. This mirrors how you'd delegate to a new colleague: micromanage at first, then step back as trust is earned.

The override button should always be visible. Not buried in a settings menu. Visible, in context, at all times. "Stop" and "Undo last action" are not edge cases. They are the core of the trust contract. If a user knows they can always stop the agent, they are far more willing to let it run.

Sandbox mode is worth a dedicated mention for high-stakes workflows in finance, healthcare, or legal contexts. Let users run a simulation first: "Preview what this agent would do" before it actually does it. This converts the most sceptical users into willing adopters.

Designing for Failure, Because Agents Fail Differently

Traditional software fails with error codes. AI agents fail in much messier ways.

Ambiguous input is where most teams get surprised. The user said "send an update to the team." Which team? What kind of update? Traditional software throws a validation error. An agent might guess, and guess wrong. The design response: when the agent detects ambiguity, it surfaces a clarifying question before acting, not an apology after.

Partial results happen when an agent hits a permission wall or a service error halfway through a task. The wrong response is to fail silently or pretend the result is complete. The right response is to show exactly what was retrieved, mark what's missing, and give the user a clear path to resolve the gap.

Hallucination and low-confidence outputs are the trickiest failure mode. Unlike a 404 error, a hallucinated answer looks like a real answer. The design obligation is to make confidence levels visible at the output level, not hidden in a tooltip or a settings page. If the agent is uncertain, that uncertainty should be in the UI.

Timeout and abandonment will happen on long-running tasks. Design a clear recovery state: "Your agent paused on step 3 of 7. Resume or start over?" Users can tolerate interruption. They cannot tolerate losing their work invisibly.

The New UX Contract

For most of UX history, the designer's job was to make things usable, accessible, and satisfying to use. That contract has expanded significantly.

Designing agentic products now means owning accountability for the rules of engagement between human and machine. When should the agent act independently? When should it ask? When should it refuse entirely? These are not engineering decisions. They are design decisions with ethical weight.

Designers working on agentic products need to think about three things that were not in the job description before:

Consent architecture means asking what the user actually authorised, and whether they understood it when they did. An onboarding toggle labelled "Allow agent to manage my calendar" is not meaningful consent.

Auditability means users can review everything the agent did, after the fact. A full action log is not a developer tool. It is a basic user expectation for any autonomous system acting on their behalf.

Refusal design means thinking carefully about how the agent communicates what it cannot or will not do, without eroding the user's trust in the product overall.

This is genuinely new territory for most UX practitioners. It is also the most interesting design problem of the decade.

Closing Thoughts

The capability gap between humans and AI agents is closing fast. The trust gap is where the real work is.

Trust in agentic products is not built through marketing copy or onboarding tooltips. It is built through every design decision you make about transparency, control, and failure. Users will forgive an agent that makes a mistake and recovers well. They will not forgive one that fails silently.

The teams shipping trustworthy AI agents in 2026 will not necessarily be the ones with the most powerful models. They will be the ones who thought hardest about what users see, what they can control, and how the system behaves when things go wrong.

That is a UX problem. And it is one worth getting right.