Super Artifacts

Make one version of your template everybody’s

super_release_template

Release one version of your template so others can build from it, live at once to the reach visibility sets; the result names its trust tier (Official, Verified or Community). Forward only (release_moves_backwards): earlier versions stay, and nothing is deleted. A private demo needs demoConsent: true. A runtime, prompt, parts or data change leaves a Verified badge behind. Public: account 7 days old (publisher_too_new), 10/day, 3/template/hour (rate_limited), 20 templates (too_many_templates), no tier words (reserved_wording), no credential (secret_in_template), paid plan (plan_required). Writing the draft is super_template_save.

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>",
      "version": "<version>"
    },
    "name": "super_release_template"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes
`version`	Yes
`visibility`	No	`unlisted` (default): by slug. `public`: marketplace. `workspace`: team shelf, members only.
`demoConsent`	No	Default false. Makes the demo artifact, and its data, public.
`sampleConsent`	No	true: show the sample on the public listing. Omit: unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: confirms forward-only movement (`release_moves_backwards`) and that earlier versions persist with nothing deleted, which adds real detail to destructiveHint=false. It also enumerates rate limits (10/day, 3/template/hour), quota caps, and specific failure codes (`publisher_too_new`, `reserved_wording`, `secret_in_template`, `plan_required`), plus the side effect that a Verified badge is left behind on content changes.

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-loaded with purpose and the sibling pointer, then a compact block of constraints and error tokens — no filler sentences. The opening sentence is dense to the point of being hard to parse, which costs it a point, but every clause carries distinct information.

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 release/publish mutation with five parameters and no output schema, it covers the outcome (named trust tier), side effects (badge retention, nothing deleted), consent requirements, and every enumerated failure condition. An agent has everything needed to invoke it correctly and interpret rejections.

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 60%, so the description compensates where it matters: it explains that `visibility` sets the reach and that `demoConsent: true` is required for a private demo, adding use-case meaning beyond the schema's plain definition. `slug`, `version`, and `sampleConsent` are left to the schema, which handles them adequately.

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

Purpose4/5

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

States a specific verb and resource ("Release one version of your template") and clarifies the outcome (others can build from it at the reach `visibility` sets, result names a trust `tier`). It also explicitly distinguishes itself from the sibling super_template_save, which is the draft-writing step. The phrasing "live at once to the reach `visibility` sets" is grammatically awkward and slows comprehension slightly.

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?

Names the alternative path explicitly ("Writing the draft is super_template_save") and lays out concrete conditions for private demos (`demoConsent: true`) and public releases (account age, rate limits, plan). It stops short of a full when-not-to-use statement, but the routing to the sibling covers the main ambiguity.

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

All Super Artifacts tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?