Charming

set_template

Enable a Charming Template for people who can already read the source App, and optionally publish it in Charming's public Template directory so anyone can discover and copy it. Listed grants no access to the live source App or its data. Use this when the user wants independent copies or a public Template listing, not access to the live App. Each copy belongs to the signed-in visitor from creation. Optional listing fields are a patch: title, summary, content_markdown, category, cover fields, and gallery change only when supplied. Publishing with listed: true requires a nonblank resulting title and summary; every cover or gallery image needs nonblank alt text and must reference an image asset from this App. Pass listed: true to also mark it for discovery, or listed: false to unlist it. Omitting listed is a patch, not a reset: it leaves the current listed state exactly as it is (an already-listed app stays listed; a never-listed app stays unlisted), so re-affirming that an app is a template never surprises the owner by delisting it. Idempotent: calling with the same effective listed state as the current one returns the same URL without re-firing analytics. Anonymous apps cannot be made into templates; the app must be claimed first.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	Template listing title; null clears it
`app_id`	Yes	The app ID (UUID) to publish as a template
`listed`	No	Whether to also list the app in Charming's public template directory for discovery. `true` lists it, `false` unlists it. Omit this to leave the current listed state untouched — it is NOT a default-false reset, so omitting it never unlists an already-listed app.
`gallery`	No	Ordered screenshot records; null or an empty array clears the gallery
`summary`	No	Template listing summary; null clears it
`category`	No	Template listing category; null clears it
`cover_alt`	No	Nonblank cover alt text; supply with cover_asset_key
`cover_caption`	No	Optional cover caption; supply with cover_asset_key
`cover_asset_key`	No	App asset key for the cover image; null removes the cover
`content_markdown`	No	Long-form Template listing content; null clears it

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Indicates success. Errors arrive as content with isError:true.
`listed`	Yes	Whether the app is currently listed in the public template directory, reflecting the ACTUAL resulting state — not necessarily the call's `listed` input, since an omitted `listed` leaves the prior state unchanged. A template can be copyable without being listed.
`message`	Yes	Consequence copy the agent should surface verbatim to the user when reporting the change. Spells out that other people will get their own copy — the user's data is untouched — and, when listed, that strangers can discover it.
`advisories`	No	Structured non-fatal advisories, including authoring issues and unread staff feedback responses. Each advisory.summary is also appended to the text content for the LLM path.
`public_url`	Yes	Canonical `/templates/<handle>/<app-name>` Template page. The URL stays the same while the Template is listed or unlisted. Existing App readers can copy an unlisted Template; anyone can copy it when Listed. The original is never mutated. Free of write-capable `?t=` tokens.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 10, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses unique behavioral traits: the difference between 'listed' and live access, that each copy belongs to the signed-in visitor, idempotency, and odd patch semantics for `listed` omission. It adds valuable behavioral context entirely absent from the schema/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 wordy but each sentence carries a distinct, non-redundant idea—purpose, access scope, usage, ownership, patch behavior, listing requirements, idempotency, anonymous restriction. It is front-loaded with the primary purpose and maintains a logical left-to-right order that maximizes comprehension.

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?

For a tool that both mutates a property and has optional performance community pages, the definition gives all necessary : use cases, side effects, parameter behavior, validation constraints, and an edge case ('Anonymous apps cannot be made into templates'). Output schema being present, no return-value description 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?

While schema coverage is 100%, the description enriches parameter understanding with patch semantics ('change only when supplied'), the nonblank title/summary prerequisite for listing, alt text and asset-key validation for images, and the non-reset behavior of omitting `listed`. These constraints are cross-field and not captured by per-parameter schemas.

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 first sentence names the verb ('Enable') and resource ('Charming Template'), and immediately distinguishes the tool from siblings by noting it is 'not access to the live App or its data'. This clear separation from set_public, share_app, or search_templates is self-evident.

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?

Explicitly provides the 'when' in the second sentence: 'Use this when the user wants independent copies or a public Template listing, not access to the live App.' It also supplies a prerequisite and excludes anonymous apps, giving a clear decision boundary between this and the alternative tools.

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

All Charming tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.