Skip to main content
Glama

Publish an artifact

super_publish

Publish a page at a stable URL; the same slug adds a new version, which the URL serves at once. Earlier versions stay and can be served again; nothing that existed before the call is deleted. Always give the person the url from the result, even on updates. Send html, or values for a template that carries a runtime, not both. Without policy a form, input or saved state stores nothing; CMS rows a page edits go in policy.collections. When retained storage is full it refuses with plan_limit and deletes nothing. A template becomes everybody’s through a release, not a publish.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "super_publish"
  }
}

Input Schema

NameRequiredDescriptionDefault
htmlNoComplete self-contained index.html.
kindNoDefault `page`. `dashboard` labels a page of mostly live data.
slugYesKebab-case, 3–63 chars, under your key’s handle: it updates one there you are Editor on. Another workspace’s artifact: publish from its dashboard.
filesNoWith `html`: small assets. ≤200, 5 MiB each, 10 MiB total, decoded.
titleNoUnder 60 chars. Default: page <title>.
policyNoData policy v1. Visitors submit to a sheet (perUser single, upsert, a field per question), a log (many, append-only) or a shared doc (shared, key). CMS rows: `collections`. See super_help data.
promptNoOptional: the request it answers, on its card.
valuesNoFilled slots for `template`'s runtime, by slot name; `json` slots are schema-checked.
datasetNoWith `values`: overrides the declaration's `dataset.key`.
uploadsNouploadId from super_upload; its files ship with the page.
templateNoThe template built from (provenance); required with `values` or `instances`.
triggersNoDeclared agent triggers: key, prompt, optional label, on, who, agent, input, when, once. At most 8 and 12 KiB; omitted on redeploy keeps the previous set.
continuesNoWith `values`: the dataset key this one succeeds.
instancesNoInstead of `slug`/`values`: several pages of one `template`.
collectionNoGallery grouping label, not a content collection.
valuesFileNoWith `uploads`: the staged JSON file to read `values` from.
visibilityNoFrom version 1. Default: the workspace default; public is set after.
descriptionNoLink-preview sentence, under 200 chars. Default: `prompt`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / triggers
      Added value: +{
      +  "description": "Declared agent triggers: key, prompt, optional label, on, who, agent, input, when, once. At most 8 and 12 KiB; omitted on redeploy keeps the previous set.",
      +  "items": {
      +    "type": "object"
      +  },
      +  "maxItems": 8,
      +  "type": "array"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / prompt / description
      Previous value: -"One sentence on why; shown in the gallery."New value: +"Optional: the request it answers, on its card."
    • changedInput schema / required
      Previous value: -[
      -  "slug",
      -  "prompt"
      -]New value: +[
      +  "slug"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / collection / description
      Previous value: -"Gallery grouping label."New value: +"Gallery grouping label, not a content collection."
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: earlier versions remain, the URL serves the new version immediately, missing `policy` means forms and saved state store nothing, and full retained storage refuses with `plan_limit` without deleting anything. These details align with the non-destructive annotation and tell the agent what happens on update and failure.

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?

The description is front-loaded with the core publish-and-version behavior and is appropriately sized for an 18-parameter tool. Some clauses are telegraphic, such as 'CMS rows a page edits go in policy.collections,' but every sentence adds behavioral or routing information rather than repeating the schema.

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 18 parameters, nested objects, and no output schema, the description covers the essential semantics: stable URL versioning, non-deletion, mutual exclusivity of `html` and `values`, policy requirements, storage failure behavior, and template-release distinction. The schema documents the individual parameters, and the description supplies the missing operational context.

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 coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema by making the `html` versus `values` exclusivity explicit, explaining that `policy` is required for forms/input/saved state, and clarifying that CMS rows belong in `policy.collections`.

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 states a specific verb and resource: 'Publish a page at a stable URL,' and explains the same-slug versioning behavior. It also distinguishes this operation from template release, so an agent can tell it apart from super_release_template without opening either schema.

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 clear usage constraints: send `html` or `values`, not both, and use a release rather than a publish when a template should become available to everyone. It does not name every sibling alternative explicitly, but the key when-to-use and when-not-to-use conditions are present.

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.

Resources