Most agent demonstrations stop at a technical milestone: the agent can call a tool. That proves the integration. It does not prove that an employee can complete the work predictably—or that the organisation can operate the experience at scale.
This viewpoint expands on the MCP Apps video I shared in March 2026, using the current ESS-MCP reference build and MCP Apps specification to ask what the interaction pattern should prove for a customer.
That is why MCP Apps matter. A tool description can declare an interactive UI resource through _meta.ui.resourceUri. A compatible host fetches that resource, typically renders it in a sandboxed frame, and passes the tool result into it. The app can then exchange structured data with the host and request permitted tool calls without routing every interaction back through the model. Host support and capabilities vary, so compatibility must be tested rather than assumed.
The model can still reason and orchestrate. The MCP server exposes or mediates the capability. The system of record remains authoritative. But the person gets an intentional interface for the task instead of having to express every state change as a free-text prompt.
Chat is useful. It should not carry the whole workflow.
Conversation is excellent for intent, ambiguity and explanation. It is less effective when the work needs constrained choices, visible progress, validation, comparison or confirmation. Asking a user to describe a multi-field request in prose—or asking the model to compose hidden JSON on their behalf—creates unnecessary uncertainty.
A structured MCP App can show what the agent already knows, what information is still missing and what will happen next. The user can inspect, amend and confirm. That feels less like experimenting with a chatbot and more like working with a capable colleague who has brought the right form, dashboard or decision pack to the conversation.
This is not an argument for rebuilding every enterprise application inside chat. It is a case for giving each task the smallest useful interaction surface, in the flow of work, while the systems of record remain where they are.
One shared capability layer, several ways of working
I built the open-source ESS-MCP reference implementation to test this pattern across a realistic enterprise estate. It models seven enterprise platforms, exposes 204 MCP tools and includes 76 interactive widgets. Those numbers are not the outcome, and the complete toolset is not used by every experience. The architectural proof is that shared MCP capabilities can be composed into several appropriate ways of working:
- A Microsoft 365 Copilot declarative agent using all seven remote MCP servers for human-led work in the everyday front door.
- MCP Apps within compatible hosts for structured, stateful interactions—not a separate agent surface, but an extension to the tool experience.
- Five Copilot Cowork plugins pairing Agent Skills with the relevant remote MCP connectors to produce dashboards, decks, cards and briefs.
- An autonomous demo integrated with Microsoft Agent 365 using selected MCP capabilities with agent identity, controls and telemetry.
It is a reference build, not a customer deployment, and it uses simulation or mock adapters where a live tenant would be inappropriate. Its value is architectural: a shared capability layer can serve different interaction models without rebuilding every integration for every host. Governance still has to be applied end to end across the host, identity provider, gateway or MCP server, and system of record.
A clearer buy, adopt or build boundary
The architecture creates a useful discipline. Buy the common front door, reasoning and orchestration where a platform already provides them. Adopt supported platform, SaaS-vendor or partner connectors and MCP servers when they meet the security, service and lifecycle requirement. Build where the organisation is genuinely different: its process, policy, decision logic, actions or domain-specific interaction patterns.
Remote MCP puts that capability behind a protocol boundary. The host does not need to absorb every enterprise-system implementation, and the MCP server does not need to become another chat product. The boundary improves replaceability, but it does not remove host-extension differences, SaaS API coupling, authentication, versioning, testing or support obligations.
MCP Apps complete the pattern by giving a capability a predictable interface when text alone is not enough. The fully loaded economics still need to include platform licensing or consumption, model use, MCP hosting, vendor APIs, observability, engineering, security review and ongoing support. The advantage is not “free integration”; it is a clearer decision about where custom investment creates value.
Structured does not automatically mean governed
MCP Apps can improve human control: choices can be constrained, state can be visible and consequential actions can require explicit confirmation. But the interface is never the security boundary.
An MCP App is active code. Its source and dependencies need provenance, review, patching and content-security controls. Authorisation, tenant and user scope, tool allow-lists, data validation, rate limits, audit and approval must still be enforced by the server and platform.
Telemetry is not harmless by default either. HR, payroll, sales or procurement payloads can leak into logs and traces unless they are minimised, redacted, access-controlled and governed by explicit retention and residency policies. A production-bound POC should demonstrate those controls alongside the experience.
The question is not only whether the form renders; it is whether the right identity can perform the right action, against the right data, with evidence afterwards—and whether failures leave the process in a safe, supportable state.
What I would ask an MCP Apps POC to prove
- A measurable outcome improves.Start with a baseline and target for completion, quality, latency and the business result—not just a successful tool call.
- The target host works for real users.Verify host support, accessibility, responsive behaviour, latency and consent on the clients people will actually use.
- The interaction is legible.The user can see state, missing information, choices, consequences and the boundary between suggestion and action.
- Reuse is proven where it matters.If the use case requires multiple hosts or human-led, deep-work and autonomous patterns, prove only the combinations that have real value.
- The controls survive the demo.Identity, permissions, code provenance, validation, confirmation, telemetry minimisation and human judgement are designed in.
- Reliability is operational.Test representative volume, retries, partial failure, safe rollback, monitoring and named support ownership.
- There is a named route to production.Exit criteria, fully loaded unit cost, architecture ownership and the governed scale plan are explicit.
The better question for an enterprise agent is no longer, “Can it call our tools?” It is: Can people complete valuable work through it predictably, and can we govern the result in production?
MCP Apps do not answer that whole question. But they provide the interaction layer that makes a serious answer possible.