Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Apps Playground Sort my favorite movies by rating"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A demo MCP server showcasing interactive UI capabilities using the MCP Apps Extension (SEP-1865).
🔧 MCP Tools - hello_world, list_sort, flame_graph, and feature_flags tools with Zod schema validation
📱 Apps Extension - HTML UI via ui:// resources with text/html;profile=mcp-app
📦 structuredContent - Data passed to UI via ui/notifications/tool-input
💬 Bidirectional - UIs can send messages back to chat via ui/message
🚀 Dual Transport - stdio (default) and HTTP/SSE
Related MCP server: xmcp Demo Application
list_sort — Interactive List ReorderingBefore: Agent receives list data from an MCP tool → proposes a sorted order based on its analysis → user reads text output and requests adjustments → multiple back-and-forth messages to align with actual preferences.
With MCP Apps: Agent displays a drag-and-drop interface alongside its suggested order. User applies domain knowledge to reorder items visually, or clicks "Ask AI to Sort" for the agent's reasoning—true collaboration where both contribute.
🖱️ Drag-and-drop reordering · 🤖 "Ask AI to Sort" · ↩️ Reset · 💾 Save to chat
flame_graph — Performance Profiler VisualizationBefore: Agent receives CPU profile data from an MCP tool → analyzes the JSON and identifies bottlenecks → user sees only the agent's text summary → no way to validate hypotheses or apply domain-specific context.
With MCP Apps: Agent renders an interactive flame graph and can annotate suspected hot paths. User explores the visualization with their own domain knowledge—confirming or rejecting the agent's hypotheses, drilling into areas the agent might have overlooked.
🔍 Click-to-zoom hierarchy · 💬 Hover tooltips · 🧭 Breadcrumb nav · 📊 Send frame to chat
feature_flags — Feature Flag SelectorBefore: Agent fetches flag configuration from an MCP tool → summarizes which flags exist and their status → user cross-references with deployment context → asks agent to generate integration code separately.
With MCP Apps: Agent displays a searchable flag picker with live environment status. User selects flags based on their release priorities, switches between prod/staging/dev views, and generates SDK code—agent provides data, user drives decisions.
🌍 Environment tabs · 🔎 Search & filter · ☑️ Multi-select · 📝 Generate SDK code
# Install dependencies
npm install
# Build
npm run build
# Run with stdio transport (for Claude Desktop, Cursor, VS Code)
npm run dev
# Or run with HTTP transport (for web-based clients)
npm run dev:http
# Test with MCP Inspector
npm run inspector # stdio
npm run inspector:http # HTTP (start server first)src/
├── index.ts # Main server (stdio transport)
├── http-server.ts # HTTP transport variant
└── ui/
├── hello-world.ts # Greeting UI template
├── list-sort.ts # Interactive list sorting UI
├── flame-graph.ts # Performance flame graph visualization
└── feature-flags.ts # Feature flag selector UIUse the included .vscode/mcp.json:
{
"servers": {
"mcp-apps-playground": {
"type": "stdio",
"command": "node",
"args": ["${workspaceFolder}/dist/index.js"]
}
}
}{
"mcpServers": {
"mcp-apps-playground": {
"command": "node",
"args": ["/path/to/mcp-apps-playground/dist/index.js"]
}
}
}UI resources are declared with ui:// scheme and text/html;profile=mcp-app MIME type:
server.resource(
"greeting-ui",
"ui://mcp-apps-playground/greeting",
{
description: "Interactive greeting UI panel",
mimeType: "text/html;profile=mcp-app",
},
async (uri) => ({
contents: [{
uri: uri.href,
mimeType: "text/html;profile=mcp-app",
text: HELLO_WORLD_UI(),
}],
})
);Tools use _meta.ui.resourceUri to link to a UI resource. Data is passed via structuredContent:
server.registerTool(
"hello_world",
{
description: "Display a Hello World greeting",
inputSchema: {
name: z.string().describe("Name to greet"),
},
_meta: {
ui: {
resourceUri: "ui://mcp-apps-playground/greeting",
visibility: ["model", "app"],
},
},
},
async ({ name }) => ({
content: [{ type: "text", text: `Hello, ${name}!` }],
structuredContent: { name, greeting: `Hello, ${name}!` },
})
);UIs communicate with the MCP host via postMessage JSON-RPC:
// Initialize handshake (required)
const result = await sendRequest('ui/initialize', {
protocolVersion: '2025-06-18',
capabilities: {},
});
sendNotification('ui/notifications/initialized', {});
// Listen for tool data
window.addEventListener('message', (e) => {
if (e.data.method === 'ui/notifications/tool-input') {
const { arguments: args } = e.data.params;
// Update UI with args
}
});
// Send message to chat
await sendRequest('ui/message', {
content: [{ type: 'text', text: 'User selected: ...' }]
});MIT
Query and filter sales database with interactive UI. Filter by date range, category, status, sales rep, and amount. Preview data in table format and export summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Order status filter | |
| category | No | Product category filter | |
| salesRep | No | Filter by sales representative name | |
| dateRange | No | Date range filter (default: 30d) | |
| minAmount | No | Minimum order amount filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions query/filter behavior and preview/export features but doesn't state whether this is read-only, what the output format looks like, whether it mutates data, whether results are paginated, or the response shape. For a query tool with zero annotation coverage, more disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient. The first sentence sets the purpose, the second covers output. No wasted words. Though the 'interactive UI' phrase is somewhat out of place for a programmatic tool, overall the structure is compact and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filterable query tool with 5 parameters all documented in schema and no output schema, the description covers the basic intent and output features (table preview, export). However, it omits behavior like default date range (30d, though the schema states this in the dateRange description) and doesn't clarify the export behavior or return structure, making it adequate but not complete for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 5 parameters have descriptions in the schema itself. The description does list the filter dimensions matching the parameters (date range, category, status, sales rep, amount), adding modest value by grouping them contextually. However, the description doesn't add format details beyond the schema — with 100% coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource (query sales database), and specific filter dimensions (date range, category, status, sales rep, amount). However, the mention of 'interactive UI' is confusing for a function tool, and it doesn't explicitly distinguish from siblings (though siblings are generic names like hello_world, list_sort, so no real conflict). Slightly muddled by the UI reference but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies 'use when needing to query/filter sales data' and lists the filter dimensions, giving implicit context for when to use. However, there are no explicit exclusions, when-not-to-use guidance, or alternative tool callouts. The intent is reasonably inferable but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse and select feature flags to generate SDK code. Shows flag status per environment (prod/staging/dev), rollout percentages, and tags. Multi-select flags to generate useFeatureFlag() hooks.
| Name | Required | Description | Default |
|---|---|---|---|
| flags | No | Custom flags to display (uses sample data if not provided) | |
| filter | No | Filter flags by name or tag | |
| environment | No | Default environment to show |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does describe display behavior (shows status per environment, rollout, tags) and the multi-select generation behavior. However, it doesn't disclose side effects like whether code generation modifies state, whether selection persists, or output format since there's no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering the main function and key behaviors without verbosity. The structure is front-loaded with the core purpose then supported details. Slightly could be tighter, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with full schema coverage and no output schema, the description is reasonably complete. It explains browsing behavior, the multi-select generation capability, and what data is shown. However, given no annotations and no output schema, it could say more about the generated code output or any persistence side effects to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (flags, filter, environment) with descriptions. The description adds context around the primary action (multi-select to generate hooks) but doesn't add parameter-level detail beyond the schema. Baseline 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear purpose: browse and select feature flags to generate SDK code. It uses specific verbs and mentions concrete details (flag status per environment, rollout percentages, tags). It doesn't explicitly distinguish from siblings, but the description is specific enough that differentiation is largely self-evident given the disjoint sibling names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (browsing/selecting flags before generating code) and mentions multi-select capability for generating hooks. However, it doesn't provide explicit guidance on when NOT to use this tool or suggest alternatives, and the filter/environment parameter usage is only implied through schema descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display an interactive flame graph visualization for performance profiling. Shows call hierarchy with execution time. Click frames to zoom, analyze hot paths.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Title for the profile visualization | |
| profile | No | Profile data (uses simulated data if not provided) | |
| filename | No | Source filename or profile name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses interactivity ('click frames to zoom') and that it's a display/visualization tool (non-destructive read-like operation). However, it doesn't disclose whether simulated data is used by default (though the schema hints at this), what happens with invalid profile data, or any limitations of the visualization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste. Efficiently conveys purpose, interaction model, and analytical value. Front-loaded with the core function and follows with interaction details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a visualization display tool with no output schema and no nested complexity, the description covers the essential behavior well. All three parameters are schema-documented. The interactivity and hot-path analysis disclosure give the agent enough to select and invoke it correctly. Minor gap: could state it doesn't modify anything, but this is low-risk for a visualization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all three parameters have descriptions. The description adds the note that profile uses simulated data if not provided (also in schema) and implies the title parameter. No parameter count is 0, so the description doesn't need to compensate heavily. It adds marginal insight (interaction behavior, hot path analysis) but doesn't enrich parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Display an interactive flame graph visualization for performance profiling' - clear verb+resource. Shows call hierarchy with execution time. It distinguishes itself from siblings (hello_world, list_sort, feature_flags, database_query) by the specific visualization type and profiling purpose, though it doesn't explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use in performance profiling context and mentions hot path analysis, but gives no explicit when-to-use or when-not-to-use guidance, no exclusions, and no mention of alternatives. The profiling context is implied but not stated as a requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display a Hello World greeting with optional interactive UI
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name to greet | |
| showUI | No | Show interactive UI panel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, but this is a benign, non-destructive greeting tool. The description is largely self-explanatory; there's minimal behavioral complexity. It doesn't describe the interactive UI's behavior (what happens when showUI is true), which is a minor gap, but acceptable for such a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. It front-loads the primary action ('Display a Hello World greeting') and appends the optional modifier. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with 100% schema coverage and no output schema or nested objects, the description is complete enough. The main action, the resource, and the optional behavior are all covered. A more detailed description would be overkill for this level of simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'name' and 'showUI' having descriptions in the schema. The description adds the 'interactive UI' context that maps to the showUI boolean. With full schema coverage, the baseline of 3 applies; the description offers marginal additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Display a Hello World greeting') with a clear modification ('with optional interactive UI'). It clearly communicates what the tool does, though it doesn't explicitly differentiate from the sibling tools (list_sort, flame_graph, feature_flags, database_query). The purpose is sufficiently distinct from siblings given their differing names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage (displaying a greeting, optionally with UI), but provides no explicit when-to-use or when-not-to-use guidance, and no alternative suggestions. For a simple greeting tool, clear context exists, though no exclusions or alternative recommendations are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Display an interactive list sorting UI. User can drag to reorder items, save the sorted order, or ask the AI to sort the list.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | List of items to sort | |
| title | No | Optional title for the list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal the key behaviors (interactive drag, save capability, AI-sort option), which helps the agent understand it's a stateful UI tool rather than a pure computation. However, it doesn't clarify what 'save' does, whether this persists state, what happens client-side vs server-side, or what the response/return value is (no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, no wasted words. It front-loads the core purpose and enumerates capabilities efficiently. Could arguably benefit from a second sentence on return behavior, but as written it's appropriately sized and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a UI-drawing tool with no annotations and no output schema, the description covers the main purpose and user interactions adequately. However, given no output schema, it fails to clarify what the tool returns (saved order? success status?), which is a notable gap. With only 2 well-documented parameters it's not a complex signature, but the lack of behavioral/return detail reduces completeness below the high tier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both 'items' (list of items to sort) and 'title' (optional title) are documented with descriptions. The description adds no parameter-specific detail beyond the schema, which under the coverage>80% baseline justifies a 3. It doesn't clarify item structure expectations or constraints on label/id values beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool displays an interactive list sorting UI with drag-to-reorder, save, and AI-assisted sorting. It's clear about verb ('Display') and resource (interactive list sorting UI), and the capabilities distinguish it from siblings like flame_graph and database_query. However, it doesn't explicitly contrast with any sibling sorting/search tool, so it's not a highest-scoring 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its interactive UI framing but doesn't explicitly state when this tool should be used versus alternatives. There's no 'when-to-use' or 'when-not-to-use' guidance, nor any mention of alternatives like flame_graph or database_query. The context of when you'd invoke a UI-drawing tool instead of a data-query tool is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0database_queryfeature_flagsflame_graphhello_worldlist_sortThe five tools are quite distinct: a greeting, list sorting UI, flame graph, feature flag browsing, and database querying are clearly different purposes. The only minor ambiguity is that all are interactive UI renderers, but their specific functions are well-separated enough to avoid meaningful misselection.
Names use snake_case throughout, which is consistent. However, the naming pattern is inconsistent: hello_world and list_sort are verb+noun-ish, flame_graph and feature_flags are noun-noun compound descriptors, and database_query is verb+noun. There's no consistent verb_noun convention, though all names are readable and descriptive.
Five tools is a reasonable count for what appears to be a UI playground/demo server. Each tool represents a distinct interactive component, and the count feels appropriate for the apparent scope of demonstrating various MCP UI capabilities without being bloated.
Each tool is a self-contained interactive UI demo for a distinct feature area (greeting, list sorting, flame graphs, feature flags, database queries). There's no obvious missing sibling operation for any tool since they're standalone demonstrations rather than CRUD-style APIs, though the domain is unclear — these seem to be UI showcase modules with no coherent overarching workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP Server for an Agent Task Marketplace
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/digitarald/mcp-apps-playground'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
