What Is MCP App UI? Dynamic Forms From a Tool's Schema

By Artificial Wit Team. Last updated: July 5, 2026.

MCP App UI is the form, table, or chart that appears automatically when Claude calls an MCP tool, generated directly from that tool's input argument schema instead of a hand-built front end. A tool's field names, types, required flags, and enum options are enough to produce a matching form. Nobody writes UI code for it.

Elena spent her first two months as a platform engineer at a mid-size logistics company doing the same job over and over: a new internal tool would get registered, and she'd build a small React form to match its parameters, ship it, then repeat the process for the next tool. By the fifth form, she'd started keeping a template file just to speed up the copy-paste. That's the work MCP App UI removes entirely.

This article explains what MCP App UI actually is, how the schema-to-form mechanism works, and what it looks like in two real Artificial Wit apps, Asset Management and Ticket Management.

• MCP App UI generates a form, table, or chart directly from an MCP tool's input argument schema, field names, types, required/optional flags, and enum options drive the UI automatically.
• No separate front-end build is required per tool. Configure the tool once and the UI comes with it.
• Two rendering surfaces exist: full-page sidebar dashboards and inline chat artifacts that expand into a side-panel preview.
• Artificial Wit ships two pre-built apps that use this today, Asset Management and Ticket Management, each supporting custom mail and print templates.
• Agent governance (role-based access control) still applies to what a generated UI can show or do.

What Is MCP App UI?

MCP App UI is the interactive interface, a form, table, or chart, that Claude or another MCP client renders when it calls a tool exposed through MCP, the open standard Anthropic introduced in late 2024 and formalized in the Model Context Protocol specification, built automatically from that tool's input argument schema rather than a separately coded front end. A `string` argument becomes a text field, an `enum` becomes a dropdown, and an array of objects becomes a table. The developer defines the tool once; the UI follows from that definition.

It's worth being precise here, since the naming overlaps with Anthropic's own product terminology: this isn't Anthropic's native Artifacts feature in Claude.ai. It's Artificial Wit's schema-driven rendering layer.

It builds directly on the "live artifact" concept covered in how MCP tools render as live artifacts instead of text. That earlier piece explains what a live artifact is. This one explains how the UI for it gets generated without anyone building it by hand.

Want the full picture on connecting a tool to Claude in the first place? See Artificial Wit's MCP server for the underlying endpoint this all runs on.

How the Schema Becomes a Form: The Mechanism

An MCP tool definition already includes an input schema, the same kind of JSON Schema structure used across REST and GraphQL tooling. That schema was originally meant to validate requests. MCP App UI reuses it as a UI blueprint instead.

From Input Arguments to UI Controls

MCP tool form generation follows a predictable pattern: each argument type maps to a control.

A ticket-creation tool with `order_id` (string), `issue_category` (enum), and `priority` (enum) arguments produces a form with a text field and two dropdowns, without a developer ever writing that layout. Change the schema, add a `due_date` field, and the form updates the next time the tool renders. No redeploy of a front end required.

Where This Fits: Full Dashboards vs. Inline Chat Artifacts

Generated UI shows up in one of two places. Full-page dashboards are sidebar-navigable and rendered from a manifest, with a `window.cowork.callMcpTool()` bridge that lets the dashboard call MCP tools directly. Inline chat artifacts are Chart.js-rendered charts, tables, and forms that appear inside a single chat message and can expand into a sandboxed side-panel preview mid-conversation. Both surfaces pull from the same schema, the difference is where the user sees it, not how it's generated.

See this running on a live tool. Explore Artificial Wit's MCP server to connect your first tool and watch its UI generate automatically.

Example: Asset Management App — a Table Generated From a Schema

Raj runs operations for a regional equipment rental company, tracking around 400 pieces of machinery across six job sites. Before connecting Artificial Wit's Asset Management app, checking what equipment was where meant opening a spreadsheet that three different site managers updated inconsistently.

Asset Management is one of two apps Artificial Wit ships pre-built, alongside Ticket Management. Its underlying tool takes arguments like `location_id`, `asset_type`, and `status`, an array-returning query. Because the response schema defines those as object properties, MCP App UI renders it as a sortable table the moment Raj asks Claude something like "show me all excavators at the north site that need maintenance."

Raj didn't configure a table layout. He didn't specify columns. The schema already described `asset_type`, `status`, and `last_service_date` as fields on the response, so the table generated itself with those as headers. Three weeks in, his team stopped checking the shared spreadsheet altogether, since the Claude-generated table was faster to pull up and always current.

Example: Ticket Management App — Mail and Print Templates on Top of the Generated Form

Sofia manages customer support for a specialty parts distributor, and her team's ticketing process used to end the moment a ticket was logged. No automatic confirmation email. No printable pull slip for the warehouse team fulfilling the part request.

Artificial Wit's Ticket Management app changed that. MCP App UI generates the ticket-creation form directly from the tool's input schema, `customer_id`, `part_number`, `issue_type`, the same kind of form Dana's team uses in the live artifact walkthrough: a text field for the customer, a dropdown for issue type, all built automatically.

What's new here is what happens after submission. Ticket Management supports configuring a mail template (a confirmation email sent to the customer) and a print template (a pull slip the warehouse team prints) as part of the app's setup, on top of the generated form itself. Sofia configured both once. Every ticket the generated form creates now triggers the right email and the right printout, without her writing any additional integration code.

Ready to configure your own app? Sign up free, no credit card required, and connect a tool to see its UI generate on the first call.

Why Dynamic Generation Matters: No Front-End Build Per Tool

The alternative to schema-driven UI is what Elena was doing before: a developer builds a form, table, or chart component for every new tool, then maintains it every time the tool's arguments change. That's real engineering time spent on UI plumbing instead of the actual business logic the tool exists for.

Elena estimated each hand-built form took her half a day, including the follow-up work whenever a field changed. Across the dozen internal tools her team registered that quarter, that added up to more than a full week of engineering time spent on forms alone, work that produced zero new business logic.

MCP App UI removes that step. Configure the tool's input arguments once, in the same registry used for any API-backed tool, and the rendering follows automatically. This is also where AI agent builder work connects: an agent assigned that tool inherits its generated UI without any extra configuration on the agent side.

None of this loosens agent governance. Role-based access control still applies at the tool level. Two users calling the same Asset Management tool can see a different set of columns, or no results at all for a location they aren't authorized to view, regardless of how the table itself got generated.

Read more about how Artificial Wit handles access control if governance is the first question your team asks before adopting this.

Where MCP App UI Fits in Agent Orchestration

Configurable AI agents can run as Standard, Sequential, Parallel, or Loop workflows, and MCP App UI works the same way inside any of them. An agent orchestrating a multi-step agentic workflow, checking an asset's status, then opening a ticket if it needs service, gets a generated UI at each tool call, not just the final answer.

That matters for agent orchestration specifically because:

• Each tool renders independently. A Sequential workflow that calls both the Asset Management and Ticket Management tools shows a generated table for the first step and a generated form for the second, without extra configuration.
• The agent doesn't need UI logic. The system prompt and tool assignments stay focused on what the agent should do, the rendering is handled entirely by the schema layer.
• Governance travels with the tool, not the workflow. Whatever access control applies to a tool in a Standard agent applies the same way inside a Sequential or Parallel one.

This is also where AI agent builder work gets simpler. Building an agent that orchestrates several MCP tools doesn't mean designing a UI for each step in the sequence, the UI question is already answered at the tool level.

Getting Started: Configure a Tool, Get the UI for Free

1. Define the tool's input arguments. Set field names, types, required/optional flags, and enum options in the tool registry, the same step you'd take for any MCP tool.
2. Test it in the Tool Testing Console. Confirm the schema and preview the generated form, table, or chart before a real user calls it.
3. Connect your MCP client and call it. Point Claude Desktop or any MCP-compatible client at the endpoint. The UI renders the first time the tool runs, no separate deployment step.

Most teams get from a defined schema to a working MCP App UI in the same session. There's no front-end sprint in between, dynamic MCP UI generation happens the moment the tool is called.

Frequently Asked Questions

What is MCP App UI?

MCP App UI is a form, table, or chart that Claude or another MCP client generates automatically from a tool's input argument schema, instead of a manually coded front end for that specific tool.

How is the form or table generated for an MCP tool automatically?

The tool's input schema, the same JSON Schema structure used to validate API requests, doubles as a UI blueprint. Field types map to controls: a string becomes a text field, an enum becomes a dropdown, an array of objects becomes a table.

Do I need to build a separate front end for every MCP tool?

No. Once a tool's input arguments are defined in the registry, its form or table generates automatically. Changing the schema updates the rendered UI without a separate deployment.

Can charts and tables render automatically from an API response?

Yes. If the API response includes an array of objects, MCP App UI can render it as a table. Numeric fields in a response can also drive automatically generated charts.

What's the difference between MCP UI and Claude's native Artifacts feature?

Claude's native Artifacts is Anthropic's own chat-embedded feature. MCP App UI is Artificial Wit's separate, schema-driven rendering layer that generates forms, tables, and charts from a registered tool's input arguments, usable across any MCP-compatible client, not just Claude.

Turn a Schema Into a Working UI, Without the Front-End Build

MCP App UI means the interface, the form Sofia's team fills out, the table Raj's team scans, comes from the tool's own schema, not a separate coding project. Define the input arguments once, and the rendering follows.

Elena's team stopped keeping a template file for forms nobody would need to hand-build again. Raj's team retired a shared spreadsheet. Sofia's team gained a confirmation email and a print slip on top of a form they never had to design. None of it required a dedicated front-end sprint.

Sign up free, no credit card required, and connect your first tool to see MCP App UI generate on the spot.