In 2024 and 2025, “agents” mostly meant better prompting plus a grab bag of tool calls. In 2026, the center of gravity is shifting to something more infrastructural: standard protocols for tools, discovery, authentication, and now—user interfaces.
The Model Context Protocol (MCP) has been one of the clearest examples of this shift. It started as a way to connect assistants to data systems and tools through a shared contract. The latest wave of ecosystem work suggests MCP is becoming a platform layer: not just “how the model calls tools,” but how users interact with those tools inside an agent experience.
MCP Apps: the UI extension that changes expectations
The MCP maintainers recently announced “MCP Apps” as an official MCP extension. The headline is simple: tools can return interactive UI components that render directly in the conversation—dashboards, forms, visualizations, and multi-step workflows.
This matters because it changes what “integrating a tool” means. Historically, you connected a tool and got back text. If you wanted UI, you built a separate web app. With MCP Apps, the agent becomes the web app shell. The conversation is the navigation layer, and the tool response can include interactive structure.
For platform engineers and DevOps teams, this is not just a UX novelty. It’s a distribution mechanism:
- Internal platform tools (deploys, incident dashboards, cost views) can be exposed through a single agent entry point.
- Governance can be centralized: access controls and audit logs are tied to agent sessions and tool permissions.
- Operational workflows become composable: one tool produces a UI card, another validates, another executes.
Transport is the next bottleneck (and why gRPC keeps showing up)
As soon as you add interactive UI and multi-step workflows, you hit performance constraints. Polling JSON over HTTP works, but it’s inefficient for streaming updates, resource watches, and high-frequency interactions. That’s why the ecosystem is now debating transports more seriously.
InfoQ recently reported on Google’s push for gRPC support in MCP transport, arguing that JSON-over-HTTP adds overhead and lacks type safety. The interesting detail isn’t the vendor politics; it’s the acknowledgement by MCP maintainers that pluggable transports belong in the SDK so the protocol can scale without fragmenting.
If you’ve lived through the evolution of Kubernetes client patterns, the analogy is familiar: once you have watches, streaming logs, and long-lived connections, transport efficiency becomes a product feature.
What this means for builders
If you’re building internal tooling or platform workflows, the emerging playbook looks like this:
- Model the workflow as tools first: expose actions (deploy, rollback, query logs, open incident) through MCP servers with clear schemas.
- Add UI when it reduces risk: use UI components to make “dangerous actions” explicit (confirmations, diffs, preflight checks).
- Design for observability: interactive agents must be observable like any other production system—latency, error rates, and audit trails.
For vendors, MCP Apps also sets a new bar. A “good integration” isn’t just a connector; it’s a complete workflow experience: UI, permissions, and robust transport.
The platform shift: from chatbot features to ecosystem contracts
The real story is that protocols like MCP are turning into ecosystem contracts. When tools can return UI, when transports can be swapped for performance, and when discovery and authentication are standardized, you get a new layer of interoperability.
That layer will shape how teams build internal platform portals, how third-party vendors ship integrations, and how agents are deployed in enterprise environments. The winners won’t just have better models—they’ll have better contracts.
Leave a Reply