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.

Component allowlists are the platform-level mechanism that says: the AI can render these components and only these components, in this slot. They’re enforced server-side, before the renderer is ever invoked. Allowlists are declared inside BindJS — directly on the slot property in a layout component’s property definitions. There is no separate project-wide allowlist surface; the layout author controls what children each slot accepts.

​
Where allowlists live: on the slot property

A layout component’s array or component properties declare what’s allowed inside them via the allowedComponents field: 
const properties = {
  components: {
    type: "array",
    title: "Body",
    description: "Components rendered in the main content area",
    allowedComponents: [
      "ProductCard",
      "ProductCarousel",
      "ProductComparison",
      "MediaSection"
    ],
    minItems: 1
  }
} satisfies ComponentProperties;
When the AI generates a tool call that includes a component named ProductCard, the platform checks: is ProductCard on this slot’s allowlist? If yes, render. Otherwise reject before rendering.

​
Layouts can nest

A layout component required as the root of an Interactive Tool can include child components that are themselves layouts with their own allowedComponents slots. Nesting works without changing the model — each slot is checked against its own allowlist. The full JSON schema the LLM sees describes the root layout, every slot it exposes, and every nested layout’s slots in turn — so the AI knows exactly what’s composable in each position.

​
Component groups

If a layout has multiple content areas — a main body and a sidebar, a header and a footer — declare separate properties with their own allowlists: 
const properties = {
  header: {
    type: "component",
    allowedComponents: ["HeaderBlock", "Banner"]
  },
  body: {
    type: "array",
    allowedComponents: ["Paragraph", "Image", "PullQuote"]
  },
  sidebar: {
    type: "array",
    allowedComponents: ["RelatedLink", "AdSlot"]
  }
}
Each slot is independently scoped. The AI cannot move components across slots if they’re not on the destination slot’s list.

​
Enforcement

Allowlist enforcement happens at the same point as schema validation — before the renderer sees anything:
A tool call is checked by schema validation and then by the component allowlist before the renderer is invoked. Either gate can reject and return an error to the AI.
A component reference that fails the allowlist check returns an error to the AI on retry, with the rejected component name included. The AI can adjust its response. The renderer is never invoked with disallowed components, on any surface. This is what governed means in practice — it’s not a runtime warning, it’s a server-side gate.

​
Designing good allowlists

A few principles:
  • Keep allowlists tight. The smaller the list, the more predictable the AI’s output. A layout that allows 4 components produces more consistent UI than one that allows 40.
  • Group by intent, not by visual category. Allow ProductCard and ProductCarousel in a slot meant for product browsing. Don’t allow Chart there even if charts could fit visually — they don’t fit semantically.
  • Document the allowlist’s purpose in the slot’s description so the AI understands what to use the slot for. The AI’s planner reads descriptions, not just the component names.
  • Version allowlists with the package. A new package version can expand or contract a slot’s allowlist; published Types pinned to older package versions keep the older list.

​
Where allowlists are configured in MCP App Studio

Allowlists are part of the layout component’s BindJS source. Edit them in the Components tab → component file → property definition: 
const properties = {
  body: {
    type: "array",
    allowedComponents: ["ProductCard", "ProductCarousel"]
  }
};
Saving the component publishes a new draft of the layout. Allowlist changes take effect at the next package publish.
A layout component's BindJS source open in the MCP App Studio Components editor with `allowedComponents` declared on a slot property

​
What allowlists do not constrain

  • Property values. Allowlists scope which components can appear, not what data they receive. Property-level validation (pattern, min, max, enum) handles data constraints.
  • Number of components. Use minItems and maxItems for that.
  • Component ordering. The AI chooses the order. If order matters (a header must come before a body), enforce that with separate properties rather than a single ordered array.

Build an Interactive Tool

The walkthrough that uses allowlists in context.

Governance

Conceptual: where allowlists fit alongside schema validation and audit.

Schema validation

The other server-side gate that runs before rendering.

BindJS Reference

Property types, the component and array shapes.