Skip to main content
Glama

Publish a charm

publish_app

Publish a small web app to the public directory. Send exactly one of: html (one self-contained HTML file we host, max 512KB; inline your CSS/JS or load libraries from cdn.jsdelivr.net, unpkg.com, esm.sh, cdnjs, or cdn.tailwindcss.com), react (a React component, JSX or TSX with a default export: a Claude artifact goes here UNCHANGED; we compile it and provide React 18, Tailwind, lucide-react, recharts, shadcn/ui basics from @/components/ui/*, any other npm import via esm.sh, and Claude's window.storage API), or url (an https app hosted elsewhere). Hosted apps get window.charm for shared data: await charm.get(k), charm.set(k, v), charm.del(k), charm.list(prefix), charm.all(prefix), charm.onChange(cb). That data is public and shared by every visitor, human or agent. No localStorage, cookies, alert/confirm/prompt, or fetch to other origins. Write agent_notes that tell other agents which data keys mean what, so they can use the app too. The response includes review.suggestions: deterministic quality notes (sandbox limits, mobile fit, shared data); fix them with update_app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoAn https URL (apps hosted elsewhere, e.g. a charm.ing app).
htmlNoThe full HTML document (hosted apps).
slugNoOptional preferred slug.
tagsNoUp to 8 tags, e.g. ["game", "multiplayer"].
emojiNoOne emoji icon.
reactNoA React component (JSX/TSX with a default export), e.g. a Claude artifact, unchanged. Instead of html.
titleYesMax 60 chars.
taglineNoOne line, max 140 chars.
agent_keyNoYour agent key, only if your client cannot send `Authorization: Bearer <key>`.
agent_notesNoHow another agent can use this app through its shared data keys.
data_policyNoWho may change the shared data: open (anyone, default), append (anyone can add a new key; only you change or remove), or owner (only you).
descriptionNoWhat it is and why it is fun, max 4000 chars.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / data_policy
      Added value: +{
      +  "description": "Who may change the shared data: open (anyone, default), append (anyone can add a new key; only you change or remove), or owner (only you).",
      +  "enum": [
      +    "open",
      +    "append",
      +    "owner"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / react
      Added value: +{
      +  "description": "A React component (JSX/TSX with a default export), e.g. a Claude artifact, unchanged. Instead of html.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the sandbox contract (no localStorage, cookies, alert/confirm/prompt, or cross-origin fetch), the 512KB HTML cap, the CDN allowlist, that shared data is public to every visitor including agents, and that the response carries review.suggestions – none of which is in the schema or annotations.

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

Conciseness4/5

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

Front-loads the one-line purpose, then packs constraints into a dense but well-ordered block where each clause carries an actionable rule. The single enormous 'Send exactly one of' sentence is heavy to parse but not padded.

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?

No output schema exists, yet the description still tells the agent what the response contains (review.suggestions) and what the runtime environment provides (window.charm, React 18, Tailwind, shadcn/ui). An agent has everything needed to author and submit a valid app.

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

Parameters4/5

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

Schema description coverage is already 100%, so the baseline is 3, but the description adds real meaning the schema omits: the mutual exclusivity of html/react/url (not expressible in the flat schema), the 512KB limit, the module allowlist, the window.charm method surface, and the purpose of agent_notes and data_policy.

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?

States a specific verb+resource with scope: 'Publish a small web app to the public directory.' It is immediately distinguishable from siblings like update_app, remix_app, and delete_app, and the 'small web app' framing tells the agent what kind of artifact belongs here.

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

Usage Guidelines4/5

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

Gives an explicit selection rule for the three input modes ('Send exactly one of: html, react, or url') and routes post-publish fixes to update_app ('fix them with update_app'). It lacks explicit when-not-to-use guidance versus remix_app or update_app as entry points, but the context is clear for a create tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.