AI Tooling

LoopCraft

Visual MCP-UI Integration Platform

To explore and implement the MCP-UI protocol, LoopCraft allows users to add graphical elements to their MCP tool calls, and map out interactive relationships with external AI agents.

Designed & Developed · Side Project

LoopCraft MCP-UI Builder
What's The Problem?

MCP-UI introduces a new interaction paradigm: instead of pure text conversations, AI agents can render interactive forms, dashboards, and controls directly in chat.

1.

UI in Chat Concept

What is the relationship between server design and the agent? What should the agent compose itself?

2.

Developer / Non-Developer Adoption

Will developers build MCP-UI tools? Will non-developers understand UI in chat concepts enough to create them?

3.

Business Viability

Is this paradigm commercially viable? Will users prefer interactive UIs over text responses?

What's The Scope?

A bidirectional MCP client that could connect to any MCP server, render interactive UI resources in chat.

Deliberate constraints:

  • Local infrastructure only
  • Local LLM models only (Ollama)
  • Ship > Perfect

Also, it needed to support both local (stdio) and remote (SSE/HTTP) transports with authentication.

What's The Challenge?

Navigating the gap between "technically interesting" and "commercially viable." MCP-UI could be the next major interaction paradigm—or it could be a niche curiosity that never escapes developer circles.

And things move quickly in our age of AI…

Preview Solution

Most MCP tools are command-line focused. LoopCraft treats integration as a visual design problem—see the tools, design the UI, map the interactions, export production code.

If you've built MCP servers, you know the resource format isn't complicated—but there's friction. You're switching between server logic and HTML/CSS/JavaScript for UIs, then manually typing metadata keys.

UI Builder Interface - Design

UI Builder removes that context switch. Stay in design mode—pick a template, tweak it, configure with dropdowns and toggles—then copy-paste the generated code. Clean, properly typed, MCP-UI spec compliant.

UI Builder Interface - Deploy

The Stack

Frontend
  • React 19 with TypeScript for type safety
  • Zustand for state management with localStorage persistence
  • Radix UI + Tailwind CSS 4 for a modern, accessible interface
  • Monaco Editor for code editing with syntax highlighting
Backend
  • MCP SDK (@modelcontextprotocol/sdk) for stdio and SSE transports
  • Ollama via ollama-ai-provider-v2 for local LLM with streaming
  • Vercel AI SDK for tool calling and streaming responses
  • MySQL 8.0 (Docker) for user data and template persistence

What the Hell is MCP?

Model Context Protocol

MCP is a standardized way for AI agents to connect to data outside of their environment.

It is a tool AI agents can use.

Instead of just generating text, the AI can say "I need to use a calculator" or "I need to search the web" or "I need to read this file." It pauses, uses that tool, gets the result, and then translates the response to you.

MCP-UI

MCP-UI lets AI tools show you interactive buttons, forms, and widgets instead of just text.

It's basically adding visual interfaces to AI tools. Instead of everything being a conversation, the AI can pop up actual apps and widgets for you to interact with.

Technical Overview

Started with a Next.js chat interface using @assistant-ui/react and ShadCN components. Got Ollama streaming working locally—the real challenge was nailing down the stream animation. Lots of stuttering at first.

LoopCraft Chat Interface with Ollama streaming

Transformed the chat app into a full MCP client. Wired up the SDK, handled tool registration dynamically, and got UI resources rendering correctly.

MCP Client with MCP-UI rendering demo

With the client working, I turned to the builder's content type architecture. Three rendering modes: rawHtml for native rendering, externalUrl for remote resources, and remoteDom for dynamic DOM manipulation—each with cascading renderer options.

At one point I thought about including the ability to create MCP servers as well, but decided to only focus on adding MCP-UI resources to existing, imported MCP servers. I wanted to simplify the project and keep the scope tight for a first version.

MCP-UI Builder Content Type Architecture

The builder needed predefined patterns that developers could quickly select and configure. I created a library of interactive patterns covering common use cases: button-to-tool-call mappings, form submissions, search filters, AI helper buttons, and link actions. Each pattern comes with sensible defaults while exposing the configuration options that actually matter.

The action system ties everything together. Five core action types handle the bidirectional communication: Tool for executing MCP operations, Prompt for AI messaging, Link for navigation, Intent for app-level actions, and Notify for user feedback. This gives developers a complete vocabulary for building interactive UIs without writing custom handlers.

MCP-UI Builder pattern selection interface
MCP-UI action system flow diagram
Code generation success dialog

Once a pattern is configured, the builder generates clean, production-ready code. The success dialog offers four paths forward: create another element, chain additional tools, view the generated code, or jump straight to the export tab.

The final piece: getting the code out. I built a dual-export system—integration snippets for adding MCP-UI resources to existing servers, and standalone FastMCP servers for starting fresh. Live preview renders changes instantly via MCPUIRenderer in an isolated iframe.

Save and load functionality lets you reuse templates across projects. Move from visual design to running MCP server in minutes.

MCP-UI Builder live preview system

Outcomes

Short-Form UI Dominance

Server-defined UIs work best for 1-3 turn interactions. The agent orchestrates when to show them, not what they contain. Non-developers consistently prefer interactive UIs over text for data input.

Server-Agent Relationship

Developers want control over UI structure but want agents to handle context-aware orchestration—when to show components, what data to pre-fill, which actions to enable. The server defines the "grammar," the agent constructs the "sentence."

Turn Count Effects

Short interactions (1-3 turns): Server-defined UIs dominate. Single-action forms, simple dashboards—developers want consistency.

Longer interactions (multi-stage): Hypothesis: agents need more compositional freedom as turns increase.

Composition Boundaries

The sweet spot: servers define available UI components with strict structure; agents decide which to invoke and when. This separation keeps UIs predictable while allowing intelligent context adaptation.

Current Version

Actively being developed based on user feedback and evolving MCP-UI standards.

View on GitHub