Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt

Use this file to discover all available pages before exploring further.

An MCP App is a Metabind project published as a hosted MCP server. The project’s Types — Interactive Tools and Data Tools — register as MCP tools that any MCP-compatible AI host can discover and call: Claude Desktop, ChatGPT, and any other host that speaks the protocol. When the AI calls a tool, the platform validates the input, executes the tool’s component (rendering UI for Interactive Tools, running a sandboxed handler for Data Tools), and returns the result inline in the conversation.

​
Built on open protocols

Metabind’s MCP server aligns with the open Model Context Protocol per SEP-1724, and Interactive Tools follow SEP-1865 (MCP Apps: Interactive User Interfaces for MCP). Anything you build on Metabind speaks the MCP wire format and runs in any MCP-compatible host. The native iOS and Android rendering runtimes and the Assistant SDK ship as part of the Metabind SDK.

​
The two parts of an MCP App

An MCP App is a versioned package combining Tools (Types — Interactive, Data, Content) with Components (BindJS layout, view, and data). It's distributed to MCP hosts and embedded via the Assistant SDK.
A Type is the registration unit — it tells the MCP server “this is a tool the AI can call, here is its schema, here is the component that backs it.” A component is the BindJS code that defines what the tool does or renders. The two are joined inside an immutable, semantically-versioned package.

​
Two distribution surfaces

A single MCP App definition reaches two distribution surfaces:
  • Every MCP host. Claude Desktop, ChatGPT, and any host that speaks the MCP protocol connect to your project’s hosted MCP server URL. Interactive Tools render inside a sandboxed iframe via @bindjs/renderer (React).
  • Embedded inside your own app. The Assistant SDK embeds the same MCP App as a native AI assistant inside your iOS, Android, or web app. Interactive Tools render as native SwiftUI, Jetpack Compose, or React directly in your app — same tools, same governance, same brand.
You don’t choose between these surfaces. One publish reaches both.

​
What makes Metabind’s MCP Apps distinct

  • Interactive Tools return rendered UI, not JSON text. The AI calls a tool with structured data; the platform renders an actual component and returns the bundle. Users see product cards, comparison tables, charts, photo galleries — whatever your components define — instead of a JSON dump in a chat window.
  • Schema-validated rendering. Every Interactive Tool response is validated against the tool’s input schema before rendering. Component allowlists restrict what the AI can render. The AI cannot inject components you didn’t approve, on any surface.
  • One BindJS definition, three rendering targets. Components compile to React for MCP hosts and to native SwiftUI / Jetpack Compose when embedded via the Assistant SDK. Components are written once, in a declarative SwiftUI-inspired language.
  • Governance and operations are platform features. Schema validation, component allowlists, package versioning, instant rollback, audit logging, and per-tool analytics are part of the platform — not custom infrastructure you have to build.

​
What you build is portable

Your tool definitions, schemas, and components live in standard formats: JSON Schema for tool inputs, BindJS source for components, and standard MCP protocol on the wire. You can move an MCP App’s definition between projects, organizations, or environments — and the open BindJS web renderer means a project’s Interactive Tools can render in any web surface.

Tools and Types

The registration unit that becomes an MCP tool — Interactive or Data.

Components and Packages

BindJS components, immutable packaging, semantic versioning.

Native rendering

Why one BindJS definition becomes SwiftUI, Compose, and React.

Governance

Schema validation, allowlists, audit. The production safety net.