Skip to main content
Glama
aerolalit

Pane

Create Pane

create_pane
Destructive

Hand a human an interactive UI by URL to collect structured data or approval. Build inline HTML or reuse a template; returns a URL to share.

Instructions

Hand the human a rich interactive UI by URL and (optionally) get structured data back. Build the UI as inline HTML (pass name + html) OR reuse a saved template (pass template_id). The relay hosts it and returns a URL. ALWAYS give the returned url to the human — paste it into the conversation and ask them to open it. Reach for this whenever a text reply is the wrong shape: forms, approvals, pickers, surveys, dashboards, diff/doc review, wizards. If the page captures input it emits events back to you (poll them with get_events) or mutates record collections (the record tools). BEFORE authoring: call get_skill for the events-vs-records decision + schema grammar, and the taste tool (action: get) for the human's house style — both shape the HTML you write. Returns { pane_id, url, urls, title, expires_at }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNoThe pane's UI as a complete inline HTML document. To send data back to you, the page calls window.pane.emit(eventType, payload) — every emitted eventType MUST be declared in event_schema with 'page' in its emittedBy. Read window.pane.inputData for seed data. Pass EITHER `html` (+`name`) for a one-off, OR `template_id` to reuse a saved template — not both.
nameNoShort human-readable label for the auto-created template (e.g. 'Deploy approval'). REQUIRED when you pass `html` (inline form); omit when reusing an existing template via `template_id` (it inherits the template's name).
tagsNoOptional per-pane filter tags (merged with the template's tags). ≤20 tags, ≤50 chars each; 'favorite'/'favorites' are reserved.
titleNoOptional browser tab title for the human (≤80 chars). Defaults to `name`.
callbackNoOptional webhook callback config so the relay POSTs new events to your endpoint. Shape per the relay's callback schema (e.g. { url, secret? }). Most MCP agents poll with get_events instead.
metadataNoOptional opaque JSON you can attach to the pane for your own bookkeeping (never shown to the human, queryable via run_query).
preambleNoOptional one/two-line context shown above the UI — 'who is asking, and why'.
icon_emojiNoOptional single-emoji icon override for this pane.
input_dataNoOptional seed data for this pane instance, readable in the page as window.pane.inputData (e.g. the diff to review, the options to pick from).
context_keyNoOptional natural key (e.g. 'pr-42'). Repeated create_pane calls with the same (template, key) return the SAME pane — makes retries idempotent.
template_idNoReuse an existing named template (id or slug) instead of inline HTML. The template's pinned version supplies the HTML + event/input/record schemas. Mutually exclusive with `html`/`name`/`event_schema`/`input_schema`. Create templates with the `template` tool.
ttl_secondsNoOptional pane lifetime in seconds. The relay clamps to its max; the returned expires_at is authoritative.
event_schemaNoInline form only. Declares which events the page (and you) may emit and validates each payload. Shape: { events: { '<type>': { emittedBy: ['page'|'agent'...], payload: <JSON Schema> } } }. OMIT for a read-only pane.
input_schemaNoInline form only. Optional JSON Schema validating input_data. Needed if input_data references uploaded attachment ids the page must download.
participantsNoOptional number of distinct human participant URLs to mint (default 1). Each gets its own URL in the returned `urls` array.
record_schemaNoInline form only. JSON Schema 2020-12 doc with an `x-pane-collections` extension declaring this pane's mutable record collections (todos, comments…). OMIT for an event-only pane.
template_versionNoWith `template_id`: pin this pane to a specific template version. Defaults to the template head's latest version.
icon_attachment_idNoOptional per-pane icon as a ready raster-image attachment id (png/jpeg/webp/gif). Upload it first via the `attachments` tool (scope: pane or agent).
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses key behaviors: it creates a pane (destructive), returns a URL, expires after a time, and can be idempotent with context_key. It does not contradict the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false). However, it does not mention rate limits or cost, missing a bit of transparency. Overall, it adds substantial context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately detailed without being verbose. It starts with the core purpose and an actionable instruction ('ALWAYS give the returned url to the human'), then logically flows through usage, prerequisites, and technical details. Every sentence serves a purpose, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity (18 parameters, no output schema), the description is remarkably complete. It explains the return object shape, pre-requisites (get_skill, taste), edge cases (idempotency, event schema for read-only), and how it relates to sibling tools. No essential information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. However, the description adds extensive context for each parameter: mutual exclusivity of html/template_id, required name when html provided, reserved tags, callback opt-in, seed data usage, and more. This goes well beyond the schema definitions, earning top marks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a rich interactive UI by URL, with options for inline HTML or saved template. It distinguishes from siblings by listing specific use cases and instructing the agent to always return the URL to the human. The description also references related tools like get_events, making its role clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('Reach for this whenever a text reply is the wrong shape'), lists many use cases, and advises when not to use it by mentioning alternatives (poll events with get_events or use record tools). It also instructs to call get_skill and taste before authoring, which is valuable context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aerolalit/paneui'

If you have feedback or need assistance with the MCP directory API, please join our Discord server