The Model Context Protocol (MCP) is the USB-C of AI integrations: a single protocol that lets any LLM client talk to any tool, data source, or workspace. The protocol is solved. The UI is not. In 2026 most MCP-enabled apps still look like command-line tools wearing a chat interface. Users connect a server, watch a wall of JSON scroll by, and have no idea what just got authorized, executed, or read from their machine.

The teams setting the standard, Claude Desktop, Anthropic's MCP Inspector, Cursor, Cline, Continue, are working out the UX layer in public. They show which servers are connected, which tools are available, what a tool will do before it runs, and what data left the device. None of these patterns are obvious. All of them are copyable.

This guide breaks down the seven MCP UI design patterns shaping 2026. Each one comes with a definition, the technical problem it solves, a real product example, design guidance, common mistakes, and accessibility notes.

TL;DR, the MCP surfaces users trust in 2026 make server connections visible, preview tool calls before execution, distinguish local from remote servers, and provide a one-glance audit of what data left the device. Hidden MCP is the failure mode.

The seven MCP UI patterns: a brief overview

• Server connection status surface: Best for showing which MCP servers are alive, authorized, and which tools they expose.

• Tool call previews with parameter inspection: Best for showing what an LLM is about to do before it does it.

• Local versus remote server distinction: Best for signaling data residency and trust boundary.

• Resource browsers: Best for letting users see what data a server exposes without invoking a tool.

• Prompt template galleries: Best for surfacing server-provided prompts as a discoverable library.

• Per-tool permission scopes: Best for letting users approve "read calendar" without approving "delete events".

• MCP audit log and replay: Best for showing what happened across sessions, with rollback where possible.

1. Server connection status surface

A server connection status surface is a persistent UI element (sidebar, status bar, or dedicated panel) that lists every MCP server the client is connected to, with health, transport type, and the tools each server exposes. The user knows at a glance what's plugged in.

The technical problem: MCP servers fail silently. A misconfigured stdio server crashes, a remote SSE server times out, and the user has no idea why their chat suddenly forgot how to read their calendar. Without a status surface, debugging MCP is reduced to reading logs.

Real example: Claude Desktop. Claude Desktop surfaces connected MCP servers in a settings panel with a green-dot status indicator, a list of exposed tools per server, and last-error visibility. Users can disable a single server without uninstalling the config.

How to design it. Make the connection surface reachable in one click from the main chat view. List servers with name, transport (stdio, SSE, HTTP), status, and tool count. Show last error inline with a copy button, not buried in a log file. Provide a per-server enable-disable toggle without requiring config edits.

Common UX mistakes. Hiding MCP status inside a settings page that requires three clicks to reach. Showing only a binary "connected" without naming the transport. Failing to show the tool list, so users can't tell what a connected server actually does.

Accessibility notes. Use text labels alongside status dots, never color alone. Make the status panel reachable via keyboard shortcut. Announce server-down events via aria-live so screen reader users hear about disconnections.

2. Tool call previews with parameter inspection

A tool call preview shows the user what tool the model wants to invoke, with which parameters, before it runs. The user can inspect, edit, approve, or cancel. The model never executes silently.

The technical problem: MCP tools can read files, send emails, push commits, charge cards. A model that calls "delete_file" with a wrong path during a chat turn is a support ticket waiting to happen. Without previews, users only learn what happened after it happened.

Real example: Cline and Cursor. Both pause the agent loop on tool calls and render a structured card showing the tool name, parameters, and target. Users approve, edit, or reject. Cline distinguishes read-only and destructive tools visually so the user's attention scales with the risk.

How to design it. Render the preview as a card with tool name, server source, and parameter list. Highlight destructive tools (file write, network send, money movement) with a distinct color and a confirm button that requires explicit click, not Enter. Let users edit parameters before approval. Remember per-tool auto-approve preferences across sessions.

Common UX mistakes. Showing a generic "tool call" with no parameter detail. Auto-approving everything by default. Using the same visual weight for "read_file" and "delete_repo." Making the approve button the keyboard default, which causes accidental approvals.

Accessibility notes. Approve and cancel buttons must be reachable in keyboard order with the cancel position before approve. Destructive tools must be announced as "destructive action" via aria-label. Parameter fields must be readable as a structured list, not a JSON blob.

3. Local versus remote server distinction

Local versus remote distinction is the UI signal that tells users whether an MCP server is running on their machine (stdio, local HTTP) or on a third-party server (remote SSE, hosted HTTP). The trust boundary is visible in every place the server appears.

The technical problem: a "filesystem" MCP server on localhost and a "filesystem" MCP server hosted in the cloud look identical in a flat list. One reads files on your laptop, one reads files in someone else's data center. Conflating them is a data residency problem dressed up as a config problem.

Real example: Anthropic MCP Inspector. The MCP Inspector tags every server with its transport and origin (local, remote, third-party), and renders the URL or path so users can see exactly where requests are going. The distinction shows up in every tool call card too.

How to design it. Add a "local" or "remote" badge to every server card, every tool call preview, and every audit log entry. Show the actual endpoint (file path for stdio, URL for HTTP) on hover or in detail view. Surface a warning before connecting to a remote server the user hasn't approved before.

Common UX mistakes. Showing only a server name with no origin signal. Treating local and remote servers as visually equivalent. Burying the endpoint inside an advanced config so users never see it.

Accessibility notes. Origin badges must include text ("local", "remote"), not just icons. Endpoint URLs must be selectable for screen readers. First-time connection warnings to remote servers must be announced as alerts, not toasts that disappear.

4. Resource browsers

A resource browser is a UI for viewing the resources an MCP server exposes (files, documents, database tables, calendar events) without invoking a tool call. Users can see what the model can see, before the model asks.

The technical problem: MCP servers expose "resources" alongside tools, but most clients only surface tools. Users have no way to know that a connected server exposes their entire desktop folder until the model reads a file they didn't expect.

Real example: MCP Inspector. The Inspector lists every resource a connected server exposes, with URI, MIME type, and a preview. Developers use it to audit what a server actually reveals. End-user clients are starting to copy the pattern.

How to design it. Show a resource panel alongside the tool panel in the server status surface. Group resources by type (files, calendar events, database rows) and let users preview a single resource without invoking a tool. Surface the total scope ("this server can read 2,400 files in your home directory") so the scale is visible.

Common UX mistakes. Surfacing only tools, treating resources as invisible. Showing resource lists without scope summary, so users underestimate what's exposed. Failing to update resource lists when server state changes.

Accessibility notes. Resource lists must be navigable by keyboard with type-ahead search. Resource previews must include alt text or accessible name for non-text resources. Scope summaries should be announced when a server is added.

5. Prompt template galleries

A prompt template gallery surfaces the prompts an MCP server provides (server-side reusable templates the user can invoke by name) as a browsable, searchable library inside the client. The user finds them like they'd find slash commands.

The technical problem: MCP servers can expose pre-written prompt templates (a "summarize-meeting" prompt from a Granola server, a "draft-PR" prompt from a GitHub server). Most clients never surface them. Users don't know the templates exist, so server authors stop shipping them.

Real example: Claude Desktop and Continue. Both surface server-provided prompts in a slash-command picker. Users type / and see the templates each connected server exposes, with descriptions and required parameters.

How to design it. Surface prompts in a single discoverable picker, not buried per server. Show the prompt name, source server, and a short description. Make required parameters explicit before invocation. Let users favorite prompts they use often.

Common UX mistakes. Hiding prompts behind a "templates" menu nobody opens. Showing only the prompt name without the source server. Failing to indicate required parameters until invocation fails.

Accessibility notes. The picker must support keyboard navigation and screen reader announcement of focused items. Parameter requirements must be readable before invocation. Search should be reachable via slash or keyboard shortcut, not click-only.

6. Per-tool permission scopes

Per-tool permission scopes let users approve or deny individual tools on a connected server, not the server as a whole. A user can connect a GitHub MCP server, approve "read_repo" and "list_issues," and deny "create_pr" until they explicitly allow it.

The technical problem: MCP today is mostly all-or-nothing. Connecting a server grants the model access to every tool the server exposes. A server with 30 tools, 5 of which are destructive, becomes a single yes-no decision the user makes once and forgets.

Real example: emerging in Cline and Cursor. Both have started shipping per-tool auto-approve lists where users can mark "read_file" as always-allowed but require approval every time for "execute_command." The pattern is early but spreading.

How to design it. Show a permission matrix in the server detail view with one row per tool and columns for "ask every time," "auto-approve," "never allow." Default destructive tools to ask. Surface the current permission state in the tool call preview so users see the policy that approved or paused execution.

Common UX mistakes. Treating server-level approval as sufficient. Defaulting auto-approve for all tools to reduce friction. Hiding permission state from the tool call preview, so users don't understand why their action was paused.

Accessibility notes. Permission matrices must be navigable with arrow keys and announce row and column on focus. Destructive tools must include "destructive" in their accessible name. Default permission changes must be announced via aria-live.

7. MCP audit log and replay

An MCP audit log records every tool call, resource read, and server connection across sessions, with timestamps, parameters, and outcomes. The replay feature lets users re-examine or, where possible, reverse a past action.

The technical problem: MCP actions are real-world effects (commits pushed, emails sent, files written). Without an audit trail, users can't answer "what did the model touch yesterday?" Without replay, users can't recover from an action they regret.

Real example: MCP Inspector and emerging in Claude Desktop. The Inspector logs every protocol message for debugging. End-user clients are catching up, with Claude Desktop adding a session history view that shows tool invocations chronologically with their parameters and results.

How to design it. Show audit entries in chronological order with tool name, server, parameters, and result. Allow filtering by tool or server. For reversible actions, surface a one-click undo. For irreversible actions, mark them as "no rollback available" so users don't expect one.

Common UX mistakes. Logging only model messages, not tool calls. Showing audit logs as raw JSON instead of structured cards. Hiding rollback for actions that could be reversed (file overwrites, calendar event changes). Pretending irreversible actions are reversible.

Accessibility notes. Audit entries must be navigable as a list with keyboard. Timestamps must be in a screen-reader-friendly format. Reversible-versus-irreversible status must be in text, not color alone.

How to choose which MCP UI patterns to ship first

1) Are your users developers or end users?

Developer-facing clients (MCP Inspector, Cline, Continue, Cursor) can ship resource browsers and per-tool permission scopes as the headline features. End-user clients (Claude Desktop, consumer apps) need server connection status and tool call previews first, because those patterns directly support trust and onboarding.

2) Do users connect mostly local or remote servers?

If most servers are local stdio, the local-versus-remote distinction is low priority. If users mix local with remote SaaS-hosted servers (the common direction in 2026), the distinction becomes critical for data residency and trust, and should ship before resource browsers.

3) How destructive are the tools your users connect?

If your client mostly connects read-only servers, per-tool permission scopes can wait. If your users connect filesystem, GitHub, email, calendar, and payment servers, scopes plus audit log plus rollback become non-optional. The blast radius of a bad tool call is real money or real data.

4) Do you have a debug-class user base?

Debug-class users (developers, MCP server authors) need MCP Inspector-level depth: resource browsers, prompt galleries, full audit logs with JSON. Consumer users need the friendly surface of Claude Desktop: status, previews, and a clean history. If you ship one client for both, route to the right detail level per persona.

If you've adopted MCP but your UI still looks like a developer tool wearing a chat interface, that's a design problem. AY Design helps AI-product teams turn raw MCP plumbing into surfaces consumer users actually trust. Book a design audit if your MCP integration ships but your users don't know what it does.

FAQ

What is MCP (Model Context Protocol)?

MCP, the Model Context Protocol, is an open standard from Anthropic that lets LLM clients connect to tools, data sources, and prompt templates over a uniform protocol. Any compliant client (Claude Desktop, Cursor, Cline, Continue) can talk to any compliant server, removing the need for one-off integrations per tool.

What is the MCP Inspector?

The MCP Inspector is Anthropic's developer tool for inspecting MCP servers. It surfaces the tools, resources, and prompts a server exposes, shows raw protocol messages, and helps server authors debug their implementations. It's the reference UX many client teams copy from when designing their own MCP surfaces.

What is the difference between an MCP tool and an MCP resource?

An MCP tool is an action the model can invoke (read a file, send an email, query a database). An MCP resource is a data object the server exposes for the model to read by URI (a specific file, a calendar event, a database row). Tools execute, resources expose. Clients should surface both, not just tools.

Is MCP secure?

MCP is as secure as its UI and permission model. The protocol itself supports transport security and capability declarations, but real-world safety depends on whether the client shows users what's connected, previews tool calls before execution, and distinguishes local from remote servers. Many security incidents in 2026 trace back to UI gaps, not protocol gaps.

Can I connect to remote MCP servers?

Yes. MCP supports stdio (local processes), SSE, and HTTP transports, so remote MCP servers run on third-party infrastructure and connect over the network. The trade-off is data residency: a remote filesystem server sends file contents off the device, which is a different trust decision from a local one. Good clients surface that distinction.

How do I let users approve only some tools on an MCP server?

Implement per-tool permission scopes: a permission matrix in the server detail view with one row per tool and "ask every time," "auto-approve," and "never allow" columns. Default destructive tools to ask, and surface the active policy in every tool call preview so users see why an action was paused or auto-run.

Should MCP audit logs be local or synced?

Local-first is the safer default. Audit logs contain tool parameters that may include sensitive content (file contents, email drafts, payment amounts), so syncing them to a cloud history creates a data residency surface beyond what the user expected when they enabled MCP. If you sync, surface the choice explicitly during onboarding.

What does an MCP design partner actually do?

An MCP-savvy design partner audits your protocol surfaces, redesigns the server status, tool preview, and permission flows so end users trust them, and ships the audit and rollback views that turn MCP from a developer integration into a consumer product. If your MCP integration ships but doesn't earn user trust, AY Design rebuilds the surface that does.