Skip to main content
Glama

Community Templates

community
Destructive

Publishing an app as a community template, taking your own listing back down, installing a template, and, for relay operators, reviewing submissions. Actions: publish, unpublish, get_config_contract, install, list_pending, get_submission, approve, reject, set_trust_level.

publish captures a live app (html, manifest, the seed rows of its seedOnInstall collections, and listing metadata) into a pending template. It is installable by the returned direct link but is not listed in the public gallery until an operator approves it, and it requires a verified email and no more than a few pending submissions at once. Privacy consequence: an approved template's content and its captured seed rows become public to every platform user, so seed data in a published app must be example-only rather than real personal data. attest_example_only:true records that this was checked. A template may take a per-publisher slug (namespaced as /) and a semver version defaulting to 1.0.0, and a republish under the same slug must bump the version.

unpublish is the publisher's own undo for a live listing, taken down by snapshot_id: it leaves the public gallery, search, and the direct snapshot install link. It works only on your own submissions, and a snapshot that does not exist or belongs to someone else reads as not found either way. Existing installs are unaffected, because an install is a fresh private copy rather than a live reference, so unpublishing never breaks an app someone already installed. It is idempotent, and publishing a new version is the way to put the listing back.

get_config_contract reads what a template needs at install, meaning its settings collection and its ordered config and upload steps, by ref. install creates a fresh private copy of a template for the caller's owning human, passing answers as config, where a 'config' value is a string and an 'upload' value is a pre-uploaded attachment id from the attachments tool.

The review actions are limited to the relay's configured community reviewers: list_pending returns the queue; get_submission returns a submission's full content by snapshot_id; approve lists it in the gallery, where a re-publish supersedes the app's prior approved version; reject takes a required note that lands in the publisher's app feed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoget_config_contract/install only. The template to read or install: a namespaced '<handle>/<slug>' or a community snapshot id.
noteNoreject only. The required rejection note shown to the publisher (delivered to their app feed).
slugNopublish only. Optional per-publisher slug (lowercase, 3 to 48 chars, hyphens). Gives the template a namespaced id <handle>/<slug>; a republish reuses the slug and must bump the version. If omitted, a slug is derived from the title instead of leaving the template unnamed, so this field matters only when a specific url is wanted. Slugs are immutable: renaming the template later does not move its url, so the slug chosen here is permanent.
tagsNopublish only. Up to 6 curation tags.
limitNolist_pending only. Page size (1..200).
titleNopublish only. Listing title (1 to 80 chars). Defaults to the app's manifest name.
actionYespublish: publishes one of the caller's apps as a community template (app_id; optional title/description/category/tags). Privacy consequence: publishing makes the template content and the captured seed rows (the live rows of every seedOnInstall collection, captured at publish time) public to every platform user once approved, so an app whose seedOnInstall collections hold real personal data (names, emails, addresses, messages, anything private) is not safe to publish: seed data must be example-only. attest_example_only:true records that this was checked. The capture (html + manifest + seed rows) lands pending review, installable by its returned direct link but not listed until approved; an established publisher is fast-tracked, and the response's expedited/auto_approved fields report which path it took. unpublish: takes one of the caller's own published templates back down (snapshot_id). It removes the listing from the public gallery, from search, and from the direct snapshot install link. Existing installs keep working untouched, because an install is a fresh private copy rather than a live reference. It is idempotent (unpublishing an already-unpublished template is a no-op), and a snapshot that does not exist or belongs to someone else reads as not found either way. Publishing a new version is what puts the listing back. get_config_contract: read a template's install-time config contract by `ref` (a namespaced '<handle>/<slug>' or a snapshot id): its settings_collection, ordered config_steps (each with key/kind/required/secret/choices/default), and connect_steps (inbound hooks the app receives on). An 'upload' step wants a file, pre-uploaded with the attachments tool (scope agent) and passed as its attachment id. A template installed with connect_steps provisions hook URLs, which the `ingest` tool's list action returns for the new app_id, ready to wire into the external service. install: installs a template by `ref` for the caller, whose owning human becomes the owner. `config` is { stepKey: value } from the contract: a 'config' step's value is a string, an 'upload' step's value is a pre-uploaded attachment id. An omitted required step is rejected. Returns the new app's id, slug, and url; installs always create a fresh private copy. list_pending / get_submission / approve / reject / set_trust_level are relay-operator-only review actions: list_pending (the review queue, expedited submissions first), get_submission (a submission's full html+manifest+seedRows plus external_destinations, the hosts it can send data to or pull data from, by snapshot_id), approve (snapshot_id, lists it in the gallery + supersedes the app's prior approved version), reject (snapshot_id + a required note that lands in the publisher's app feed), set_trust_level (promote/demote a publisher by handle: handle + trust_level 'new'|'established'). upgrade_check / upgrade / revert keep an already-installed app current with its source template (app_id). An install is a one-shot fork, so nothing updates on its own and there is no follow/pin: you have to ask. upgrade_check reports whether a newer live version of that app's template line exists, whether it would apply cleanly, and what it would newly be allowed to reach. upgrade applies it in place, keeping the app's address, collections and rows, and landing as a new version you can undo. It refuses outright, with no override, when the new version would strand rows the app already holds; when the new version merely asks for more than the installed one, pass accept_permissions:true, but only after showing the owner what `permission_lines` says. revert puts the app back on the version it ran before the last update, and refuses when rows written since would have nowhere to live under the older one.
app_idNopublish / upgrade_check / upgrade / revert. For publish, the app to publish. For the three upgrade actions, the installed app to act on: an installed template is a fork, so the question is whether a newer version of the template that app came from exists, which only the app can answer.
configNoinstall only. The install-time answers as { stepKey: value } from the config contract: a 'config' step's value is a string, an 'upload' step's value is a pre-uploaded attachment id. Omit for a template with no config steps.
cursorNolist_pending only. Opaque cursor from a prior next_cursor.
handleNoset_trust_level only. The @-handle of the publisher to promote or demote.
versionNopublish only. Semver MAJOR.MINOR.PATCH (default '1.0.0'). A republish under the same slug must be strictly greater than the current version.
categoryNopublish only. Optional single-word category (e.g. 'household').
descriptionNopublish only. Listing blurb (up to 200 chars). Defaults to the manifest description.
setup_stepsNopublish only. Ordered typed setup steps an installing agent follows after install (up to 20). A 'config'/'upload' step may carry a `key` naming a field of the manifest's settingsCollection that its install-time answer is written into; a 'connect' step may carry an `ingestRule` naming a manifest ingest rule it wires up. Read back via get_submission and rendered on the template detail page.
snapshot_idNoRequired for get_submission/unpublish/approve/reject. The submission's snapshot id (from publish's response or list_pending).
trust_levelNoset_trust_level only. 'established' fast-tracks the publisher's future submissions through review; 'new' reverts to full review.
changelog_noteNopublish only. A short note recorded in this version's changelog.
expect_versionNoupgrade only. The version upgrade_check reported. When given, the upgrade is refused if the offer has moved since, so a publisher shipping again mid-flight cannot slip a version past you that you never showed anyone.
long_descriptionNopublish only. Optional long-form description (up to 4000 chars) shown on the template detail page below the short blurb, for readers and search ranking. Plain text: blank lines become paragraphs, and it is escaped (never rendered as raw HTML), so write prose, not markup.
accept_permissionsNoupgrade only. Required when upgrade_check reports a non-empty `permissions` diff, meaning the new version asks for more than the installed one (new hosts it can send data to, new device capabilities, a service worker, CDN scripts). Never assume it: show the owner `permission_lines` and set this only once they have agreed. It does not clear a version that would strand rows, which nothing can.
attest_example_onlyNopublish only. True attests that the template content and the captured seed rows contain no real personal data. Publishing makes both public to every platform user, so seed data (the live rows of the app's seedOnInstall collections) must be example-only, never real names/emails/addresses/private messages. Recorded and shown to the reviewer; omitting it still publishes but is flagged to the operator as not attested.
derived_from_snapshot_idNopublish only. Optional remix/fork lineage: the snapshot id this template was derived from.

TDQS

A4.5/5.0
Behavior5/5

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

This description is exceptionally transparent about side effects and preconditions. It discloses privacy consequences ('seed data in a published app must be example-only'), idempotency ('unpublishing an already-unpublished template is a no-op'), and nuanced failure behavior ('a snapshot that does not exist or belongs to someone else reads as not found'). Annotations (destructiveHint=true) are consistent, but the description adds rich context about what gets destroyed and what remains unaffected (existing installs).

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

Conciseness3/5

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

The description is well-structured by action but quite verbose, repeating key points (e.g., the privacy warning appears in both the main description and the action parameter description). It front-loads the action list, which helps, but several sentences could be tightened without loss of meaning. The length is justified by the tool's complexity, but it does not earn a higher conciseness score.

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 complex tool with 23 parameters, no output schema, and multiple distinct operations, the description is remarkably complete. It covers return values ('returns the new app's id, slug, and url'), edge cases (idempotency, not-found behavior), permissions (relay-operator-only), and side effects (superseding prior versions). It leaves very little for the agent to infer.

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?

With 100% schema coverage, the baseline is 3, but the description adds meaningful cross-parameter logic beyond the schema—for instance, explaining how slug and version interact ('a republish under the same slug must bump the version') and what attest_example_only actually records. It also clarifies the semantic role of config values ('a 'config' value is a string and an 'upload' value is a pre-uploaded attachment id'). This elevates the value over the raw schema.

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 opens with a clear list of distinct actions ('publish, unpublish, get_config_contract, install, list_pending, get_submission, approve, reject, set_trust_level') and ties them to a specific resource ('community template'). It also distinguishes the tool from siblings by clarifying scope (e.g., 'for relay operators', 'install creates a fresh private copy'), so an agent can confidently select it for template publishing/installing operations.

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?

The description gives strong contextual guidance: it explains when each action is appropriate (e.g., publish vs unpublish, install vs upgrade) and includes explicit exclusions like 'works only on your own submissions' and 'limited to the relay's configured community reviewers'. It also references companion tools (attachments, ingest) for related steps. It stops short of explicitly naming sibling tools as alternatives (e.g., 'publisher' vs 'community'), so it misses a 5.

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.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools are clearly distinct, with row operations (list, get, upsert, update, delete, restore) well separated. Some boundaries like apps vs deploy_app and credentials vs grants require careful reading, but descriptions resolve the overlap.

Naming Consistency2/5

Tool names mix resource nouns (apps, attachments, connections) with verb_noun actions (delete_row, deploy_app). Singular and plural forms are inconsistent, and there is no uniform pattern across the set.

Tool Count3/5

24 tools is on the heavy side, but the platform's breadth (app deployment, data, auth, community) justifies the count. Each tool has a distinct role, though the set slightly exceeds the typical well-scoped range.

Completeness4/5

The surface covers the full app lifecycle: deploy, manage, delete, row CRUD with restore, attachments, credentials, and community features. Minor gaps like no dedicated row search or outbound webhook management are workable via existing tools.