• MaboaSoft Engineering Team

GenUI + MCP: How Agents Get Tools - and Build the Interface on Top

Part 2 of our GenUI series. GenUI shows results — but where does the agent get its data and actions? MCP. We show how the two layers work together end to end: MCP fetches and acts, GenUI builds the interface on top.

GenUI + MCP: How Agents Get Tools - and Build the Interface on Top

Part 2 of a 3-part series, “GenUI for Mobile Teams.” Part 1 explained what GenUI and A2UI are. This part adds the missing half: how the agent gets its data and actions, and how the generated interface sits on top of them. Part 3 is the reality check.

A generative UI is a face with nothing behind it until the agent can actually do something. GenUI and A2UI answer one question — “how does the agent show a result?” They say nothing about where the data came from or how an action runs. That is the job of the Model Context Protocol (MCP), and the two fit together cleanly: MCP is the tool layer, and GenUI builds the interface on top of what the tool returns. This part is about that pipeline.

If Part 1 was the face, this is the hands and the memory.

The mental model: MCP fetches and acts, GenUI shows

The simplest correct way to hold this in your head:

  • MCP = tools and data. The agent calls a tool (an action) or reads a resource (context) — “search flights,” “get account balance,” “query inventory” — and gets a structured result back.
  • GenUI / A2UI = the interface, built on top of that result. Once the agent has the data, it describes a UI to present it, and the client renders that with native widgets.

They are not competitors and they are not the same layer. One is how the agent reaches your backend and the user’s data; the other is how it shows what it found. In a real agentic app, they run as a pipeline.

The end-to-end flow

Here is the loop, concretely. Imagine a travel assistant inside a mobile app.

User request  →  Agent (LLM) decides it needs data/an action
              →  [ MCP tool ]  returns a structured result
              →  Agent composes [ A2UI: interface description ]
              →  Client renders native UI
              →  User taps ("book this")  →  [ MCP tool ]  →  loop

Step by step:

  1. The user asks. “Find me a morning flight to Lisbon next Friday.”
  2. The agent calls an MCP tool. It invokes a search_flights tool exposed by an MCP server, which queries your backend (or a partner API) and returns structured data — flights, times, prices — as plain JSON.
  3. The agent builds the interface on top of that data. With the results in hand, it emits an A2UI description: a list of flight cards, each with a time, a price and a “Select” button. No HTML, no pixels — a declarative blueprint referencing components from your catalog.
  4. The client renders it natively. Your Flutter, native iOS or native Android app turns that blueprint into real widgets, themed and accessible like the rest of the app.
  5. The user acts, and the loop closes. Tapping “Select” triggers another MCP tool call — book_flight — and the agent composes the next surface (a confirmation, a payment form) on top of that result.

The shape to notice: every “do something” is an MCP tool call; every “show something” is a GenUI/A2UI surface built from what the tool returned. Data flows up through MCP, interface flows back down through GenUI. That single picture is the whole integration.

MCP in plain terms

MCP is an open JSON-RPC standard, originally from Anthropic, that gives any LLM app a single way to use external tools and data. It exposes three primitives: tools (actions the agent can call), resources (read-only context it can read), and prompts (reusable templates). The point is to turn an n×m integration mess — every AI app times every tool — into n+m: build one MCP server for your service, and any compliant client can use it. Think of MCP as wrapping your existing REST or GraphQL APIs so an LLM can call them safely; it does not replace those APIs, it fronts them for agents.

Two things make MCP matter in 2026 rather than 2024. Governance: in December 2025 Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation (co-founded with Block and OpenAI, supported by Google, Microsoft, AWS, Cloudflare and Bloomberg), so it is neutral infrastructure now, not one vendor’s project. Scale: the official registry indexes on the order of 10,000 public servers, and the protocol is moving to a stateless core in the 2026-07-28 specification so servers scale behind ordinary load balancers, with OAuth 2.1 for remote auth. Adoption is early-majority — surveys put roughly 40% of software organisations in some production use — but the direction is clear: MCP is becoming the default integration layer for agents.

For a mobile app the takeaway is simple: MCP is how your agent reaches the user’s data and your backend’s actions. Whether the UI is generated or hand-built, the agent still needs tools and context, and MCP is the standard way to give it both. Adopting MCP is worth doing even if you never generate a single screen — it is how you make your backend agent-ready, reusable across every MCP-compatible client.

Where the layers sit (the wider stack)

If you see the other acronyms flying around, here is the one-line map. They sit at different boundaries — who is talking to whom:

  • A2A — agents coordinate with other agents.
  • MCP — the agent calls tools and reads data. (this article)
  • AG-UI — a runtime/event channel between your frontend and an agent backend, when you own the app.
  • A2UI — the agent describes a UI for the client to render. (Part 1)

For a mobile team, the two you touch first are MCP (tools/data) and A2UI (interface) — exactly the pipeline above.

A note on the UI wrinkle: MCP Apps

One thing can blur the clean picture, so it is worth naming. MCP did not stay text-only: on 26 January 2026, MCP Apps shipped as the first official MCP extension, letting a tool itself return interactive UI rendered in a sandboxed iframe (building on the community MCP-UI project and OpenAI’s Apps SDK). So there are now two ways to put a UI in front of an agent’s output: A2UI (native-first — the agent sends a declarative JSON blueprint your app renders with native components) and MCP Apps (web-centric — a tool returns an HTML UI in an iframe). For a native mobile app, A2UI’s native-first approach generally wins on look, feel, accessibility and performance, while MCP Apps suits web hosts and chat clients. The conceptual model is unchanged either way: tools and data on one side, interface on the other.

Continue the series: Part 1 — what GenUI actually is → · Part 3 — the reality check on hype, accessibility and legacy code →

Wiring an agent into your app — MCP tools feeding a generated UI? Book a 20-minute call → We design the tool layer and the interface layer so the whole loop works on real devices, not just in a chat window.

FAQ

What is MCP (Model Context Protocol)? An open JSON-RPC standard that gives AI agents a single, reusable way to call tools, read data/resources, and use prompt templates from any compliant server. Originally from Anthropic, it is now governed under the Linux Foundation.

How do MCP and GenUI work together? MCP gets the agent its data and actions; GenUI/A2UI builds the interface on top of the result. The agent calls an MCP tool, receives structured data, then describes a UI (A2UI) for the client to render — and user interactions trigger the next MCP tool call.

Does MCP replace my REST or GraphQL APIs? No. MCP wraps them so agents can call them; your APIs still serve human clients and traditional services.

What about MCP Apps — is that the same as GenUI? MCP Apps is a separate, web-centric way for an MCP tool to return UI (rendered in a sandboxed iframe). A2UI/GenUI is native-first (a JSON blueprint your app renders with native widgets). For native mobile, A2UI generally fits better; conceptually both keep tools and interface as distinct layers.

Resources & further reading

MCP — primary sources

A2UI & the UI layer

Going deeper (the protocol stack & comparisons)

Written by the MaboaSoft engineering team. We build and modernize mobile apps in Flutter, .NET MAUI, Xamarin, native iOS and native Android for SaaS vendors and product companies.