Forem: Gareth Dunne

Exploring MCP UI - the next integral UI layer

Gareth Dunne — Mon, 30 Mar 2026 14:00:04 +0000

Quick note: I'm looking to dive deeper into the technical nature of MCP UI in a separate post. In this post, I want to cover who is adopting MCP UI and why you should care.

What is MCP UI?

MCP UI is the natural evolution of the Modal Context Protocol. We've seen MCP servers adopted by many providers to give agents access to tools that a server would use.

However, we didn't have a real UI baked into the LLM user experience. ChatGPT or Claude, only serving text, is quite limiting when trying to take action for a user.

Think of all the significant effort that's gone into optimising web component libraries in e-commerce, travel, task managers, and analytics tools throughout the years.

All these tried and tested UX principles are currently being omitted from the LLM user experience. You're telling me that after all these years of handcrafting these component libraries, we don't get to use them in this next wave of web interactions?

Well, not quite, because MCP UI allows us to bring the UI back into the forefront of the LLM experience. There is currently too much negativity about the role of FE developers in this AI world, so I believe MCP UI could inject a bit of life and complexity back into the frontend space. As a result, I want to explore who is using it.

Who are the big players betting on MCP UI?

A new protocol is only as good as its adopters, and reassuringly, some big names have already embraced MCP UI.

Shopify

Shopify appear to be a huge advocate of MCP UI. They see the huge potential upside in the future of agentic commerce. They are an early adopter of MCP UI in their agent MCP server.

Shopify's Catalog MCP

Shopify provide a very nice developer experience here, and the adoption makes perfect sense in the context of e-commerce. Bringing elements such as product cards and checkout systems into agentic search seems like a natural fit.

Providing another vertical where developers can build in opens up a huge ecosystem for MCP UI applications. It's definitely worth keeping an eye on how things progress here. A lot of standards for MCP UI has the potential to be molded by Shopify given their track record for great developer experience.

Admittedly, I am not fully tuned into the latest in Shopify developer experience, but I have previously built a handful of apps within the ecosystem. I found the experience to be much better than other similar ecommerce platforms.

The engineering org within Shopify is well respected in the industry, and I'd recommend looking at some of the engineering content they are putting out.

OpenAI and Stripe (Agentic Commerce Protocol)

The Agentic Commerce Protocol is an open standard for programmatic commerce flows between buyers, AI agents, and businesses. This lets businesses render checkout elements in an AI chat.

It's an open-source project, but OpenAI and Stripe initially developed it and are now pushing it as the de facto standard in this new wave of shopping through agents.

The breakdownof the protocol can be summarised here:

For businesses - Make your products and services available for purchase through AI agents.
For AI Agents - Embed commerce into your AI chat without being the merchant of record.
For payment providers - Process agentic transactions by passing secure payment tokens between buyers and businesses through AI agents.

I've worked on checkout systems in the past; they are hugely complex, with every payment method having its own unique integration and compliance requirements.

It only makes sense that massive tech companies are trying to build a stable protocol around this. Especially, given the precarious nature of AI agents, such as prompt injection, hallucinations etc.

From my perspective, the transactional nature of e-commerce and buyers' intent as reflected in search terms via AI chat are enough to spur this agentic technology forward.

How UI elements are built in an agentic commerce flow is going to be particularly important as the conversion rate depends on well-defined and contextual components.

Building UI in this system requires a reframing of how users transact. No longer will there be a branded storefront surrounding the checkout process; instead, there will be micro elements that will need to be more direct and clear than ever before.

The agent owns the checkout flow end-to-end. It surfaces options, captures payment details and keeps buyers in the loop. For us developers, this alone requires a rethink of the UI for a buyer/seller model.

Security Concerns

By integrating with an MCP provider like Shopify, many of the typical security considerations are offloaded to a third party. This doesn't mean there aren't any to consider, but compared to something like Clawbot, which notoriously gives free rein to an agent in your OS - developing with MCP UI seems like an agentic area where one doesn't need to worry nearly as much about a brittle unsecure ecosystem.

It's also completely feasible that I'm wrong here, and this wave of MCP UI comes with an onslaught of dependencies with critical vulnerabilities.

Powering up the widget

Nothing is certain in this ever-changing space, but I'm starting to hedge my bets on the MCP UI/Agentic Commerce being the future. Imagine bringing the complex logic of a web application into a widget chat. It flips the conventional client-server narrative on its head. Because now we have a client, a sever and an agent in the flow. Although adding another point of failure comes with its own set of problems, I'm sure they will pan out as this technology expands.

Listen, a lot of my career has been frontend dominant, so I have a natural bias towards a new wave of frontend problems to solve. But if this truly is how we will provide UI for users going forward, we have to adapt to this user experience. It's a narrower focus for sure, but the problems we will be solving have the potential to be interesting, complex and industry-specific (e.g., e-commerce).

https://dev.to/dunne_dev/why-im-pivoting-to-security-as-a-frontend-engineer-4nkm

Gareth Dunne — Sun, 29 Mar 2026 14:39:58 +0000

Gareth Dunne

Mar 29

Why I'm pivoting to security as a Frontend Engineer.

#newsletter #frontend #security

Comments

5 min read

Why I'm pivoting to security as a frontend engineer. https://dev.to/dunne_dev/why-im-pivoting-to-security-as-a-frontend-engineer-4nkm

Gareth Dunne — Sun, 29 Mar 2026 14:37:28 +0000

Gareth Dunne

Mar 29

Why I'm pivoting to security as a Frontend Engineer.

#newsletter #frontend #security

Comments

5 min read

Why I'm pivoting to security as a Frontend Engineer.

Gareth Dunne — Mon, 02 Mar 2026 15:26:00 +0000

Security from a Frontend perspective

I’ve been lucky to work as a software engineer for past decade. For those first 5 years, I’ve focused primary on the frontend. I’ve leaned into full stack in recently but I still primarily view things through a frontend lens.

With doom and gloom consuming a lot of the frontend space (a recent Tailwind story comes to mind!) - I’ve had to reassess what aspects of the role are worth doubling down on.

Thankfully, I’ve been exposed to a lot of the security space in my full time job (Cloudsmith). Tracking the lifecycle of our precious NPM dependencies has really opened my eyes to how vulnerable libraries in our projects truly are.

With that in mind, I want to go over why I’m pivoting to a more security focused view of the frontend role and why I think it’s beneficial to frontend developers career.

Why this, why now?

When I talk about security in the frontend, I’m not exactly talking about cross-site scripting (XSS), session hijacking, unsantized inputs etc. While these are important security fundamentals, security issues are cropping up more generally in a frontend developers workflow.

This could be in:

NPM packages we pull in
Visual studio code extensions we install
CI/CD deployment flows we use
AI and flavor of the month agentic tools that we use

That list is only a snapshot of vulnerable areas. In a way, it feels like the walls are closing in on us in relation to attack vectors across the whole lifecycle of frontend code.

I want to zone in on a couple of specific incidents that should really highlight how close to home security incidents are becoming for the frontend.

Critical Security Vulnerability in React Server Components

Photo by Lautaro Andreani on Unsplash

This incident was perhaps unavoidable for any modern FE developer. We most likely all deal with the server app pattern in our projects - whether that’s in Nextjs or otherwise.

The ability to call a server function from the client is a novel piece of functionality, however, if a potential attacker is unauthenticated, they were still able to achieve remote code execution - which is exactly what happened here.

The knock on effect to other frameworks increased the likelihood of your project being affected.

These included:

Nextjs
React Router
React Native

The industry pivot towards the app router pattern increased the complexity of the frontend domain but it also widened the surface area of frontend vulnerabilities. It’s something I’ve taken for granted with new innovations in our space.

NPM supply chain attack (Shai-Hulud)

Photo by Paul Esch-Laurent on Unsplash

Perhaps the most significant NPM attack in years, the Shai-Hulud malware attack really made the world take notice.

Essentially, billions of weekly downloads on NPM were at risk because of a malware injection due to a compromised NPM author due to a successful phishing email.

This was such a wide surface area that it should have been absolutely catastrophic, however, the malware targeted crypto wallets and didn’t seem to come away with a massive haul.

Regardless, this left a lot of organization and developers reflect on what dependencies are being pulled into their projects and why.

But take a look at some of these dependencies that were affected:

chalk@5.6.1
debug@4.4.2
ansi-styles@6.2.2

As a frontend developer, these names should seem familiar as they commonly feature in the package.json files of many project.

But they don’t have to be just referenced there, one of your dependencies could just reference any of the above packages as their sub dependencies and your project would be at risk.

This is when it started to unravel for me the endless loop of dependencies pulling sub dependencies really affects a developer’s visibility.

Unfortunately, this was only phase one of the Shai-Hulud wave of attacks. I will cover the subsequent waves in later posts as they were even more sophisticated with a wider impact (Shai-Hulud 2.0).

Visual Studio Code Compromises

Photo by Rubaitul Azad on Unsplash

I’m also concerned that threat actors are weaponizing the Visual Studio Code (VSC) extension ecosystem.

This is especially egregious as malware has been published via the ESlint Prettier config linting extension, which incredibly common to be installed within a dev’s workspace.

And there seems to be a playbook for malicious actors to create fake Prettier extensions as another entry point for vulnerabilities.

Many developers (including myself at times) would rarely give second thought to installing a VSC extension. The assumption being that the marketplace is curated and there is good quality control. But assumptions like these create the right environment for these incidents to happen.

It’s why I want to learn more about preventive measures and best practices, especially as it relates to frontend tools and deployments.

There has been such a wide ecosystem being created by NPM and with it, so many dependencies being pulled into our frontend projects. A more critical eye is required to avoid security headaches.

I will be leaning into the security side of the frontend, but will continue to cover other interesting topics too. If that interests you, please follow me at Frontend Firewall for more!