Skip to main content
Glama

riddle_publish

Destructive

Publishes one or many Riddles, or takes them off the web again with publish: false (there is no unpublish tool). A published Riddle's public URL is the response's "context.viewUrl" - report that, never one spelled from the UUID (hosts differ per environment). With UUID the response is the riddle_get envelope with the new state under "context.published" ("omit" shrinks it the same way); with UUIDs (max 100) it is the bulk envelope, one compact entry per Riddle instead of a build configuration - not atomic: a Riddle that cannot be (un)published is that entry's "error", the rest still go through (riddle://reference/concepts/bulk). PUBLISHING: a refusal is error "RIDDLE_PUBLISH_VALIDATE" carrying "validationErrors", one {message, code} per reason ("MIN_ONE_BLOCK", "MIN_ONE_RESULT", "REDIRECT_RESULT_WITHOUT_URL", "LOGIC_DEAD_ENDS", ...) - fix them all and publish again. Non-blocking findings arrive as "validationWarnings" on a FAILED and on a SUCCESSFUL publish alike (the Riddle is live either way): report them, do not retry. Only a publish produces either list - riddle_builder_validate dry-runs a build configuration, not a publish. UNPUBLISHING: a LIVE Leaderboard with active Riddle connections is refused ("RIDDLE_UNPUBLISH", same list naming what is in the way) - riddle_delete it instead, which is not blocked by the connections and cleans up the connected Riddles. Unpublishing a Riddle that is not live is a no-op that says so in a "message" - read it before reporting a Riddle as taken offline, because "context.published.at" is null whether it was never published or already offline. Codes and the draft-vs-live model: riddle://reference/concepts/publish. Only if the Riddle's origin.writableByThisKey is true (riddle_get, riddle_list): riddle://reference/concepts/access.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
UUIDNoOne Riddle's UUID. Pass this or UUIDs.
omitNoriddle_get's "omit", for the single-UUID response. Ignored with UUIDs (the bulk entries carry no build configuration).
UUIDsNoSeveral Riddle UUIDs, e.g. ["6FA740EW", "OllsevHa"] (max 100). Pass this or UUID.
publishNotrue (the default) publishes the Riddles, false takes them off the web again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / UUID / description
      Previous value: -"The UUID of the single Riddle you want to publish or unpublish. Pass either this or UUIDs."New value: +"One Riddle's UUID. Pass this or UUIDs."
    • changedInput schema / properties / UUIDs / description
      Previous value: -"Several Riddles to publish or unpublish at once, as Riddle UUID strings, e.g. [\"6FA740EW\", \"OllsevHa\"] (max 100). Pass either this or UUID."New value: +"Several Riddle UUIDs, e.g. [\"6FA740EW\", \"OllsevHa\"] (max 100). Pass this or UUID."
    • changedInput schema / properties / omit / description
      Previous value: -"Same \"omit\" parameter as riddle_get's, applied to the single-UUID response envelope (see riddle_get for the full description). Has no effect on the bulk (UUIDs) response, which never carries a build configuration to begin with."New value: +"riddle_get's \"omit\", for the single-UUID response. Ignored with UUIDs (the bulk entries carry no build configuration)."
  2. Changed9 schema fields changed
    • addedInput schema / oneOf
      Added value: +[
      +  {
      +    "properties": {
      +      "UUID": {
      +        "not": {
      +          "type": "null"
      +        }
      +      },
      +      "UUIDs": {
      +        "const": null
      +      }
      +    },
      +    "required": [
      +      "UUID"
      +    ]
      +  },
      +  {
      +    "properties": {
      +      "UUID": {
      +        "const": null
      +      },
      +      "UUIDs": {
      +        "not": {
      +          "type": "null"
      +        }
      +      }
      +    },
      +    "required": [
      +      "UUIDs"
      +    ]
      +  }
      +]
    • changedInput schema / properties / UUID / description
      Previous value: -"The UUID of the single Riddle you want to publish. Pass either this or UUIDs."New value: +"The UUID of the single Riddle you want to publish or unpublish. Pass either this or UUIDs."
    • removedInput schema / properties / UUIDs / definition
      Removed value: -{
      -  "items": {
      -    "pattern": "^[A-Za-z0-9]{4,32}$",
      -    "type": "string"
      -  },
      -  "maxItems": 100,
      -  "minItems": 1,
      -  "type": "array",
      -  "uniqueItems": true
      -}
    • changedInput schema / properties / UUIDs / description
      Previous value: -"Several Riddles to publish at once, as Riddle UUID strings, e.g. [\"6FA740EW\", \"OllsevHa\"] (max 100). Pass either this or UUID."New value: +"Several Riddles to publish or unpublish at once, as Riddle UUID strings, e.g. [\"6FA740EW\", \"OllsevHa\"] (max 100). Pass either this or UUID."
    • addedInput schema / properties / UUIDs / items
      Added value: +{
      +  "pattern": "^\\s*[A-Za-z0-9]{4,32}\\s*$",
      +  "type": "string"
      +}
    • addedInput schema / properties / UUIDs / maxItems
      Added value: +100
    • addedInput schema / properties / UUIDs / minItems
      Added value: +1
    • changedInput schema / properties / omit / items / enum
      Previous value: -[
      -  "build",
      -  "warnings",
      -  "nextBlockId",
      -  "published",
      -  "context",
      -  "build.omittedDefaults"
      -]New value: +[
      +  "build",
      +  "warnings",
      +  "nextBlockId",
      +  "published",
      +  "context"
      +]
    • addedInput schema / properties / publish
      Added value: +{
      +  "default": true,
      +  "description": "true (the default) publishes the Riddles, false takes them off the web again.",
      +  "type": "boolean"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark destructiveHint=true and idempotentHint=false, but the description goes far beyond: non-atomic bulk semantics (per-entry errors, rest proceed), exact error codes (RIDDLE_PUBLISH_VALIDATE, RIDDLE_UNPUBLISH), validationWarnings appearing even on success, and the unpublish no-op message quirk. This is unusually rich behavioral disclosure.

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 core verb and the publish:false inversion, then layers PUBLISHING/UNPUBLISHING sections. Dense but nearly every clause is actionable; the only cost is readability from a long single block with heavy parentheticals.

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?

With no output schema, the description carries the return-value burden fully: names context.viewUrl as the public URL to report, context.published state, the compact bulk envelope, validationErrors/Warnings, and the no-op 'message'. Complete for a mutating tool of this complexity.

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, but the description adds real meaning: publish:false semantics, omit shrinking the single-UUID response, the UUID-vs-UUIDs response shape divergence, and the max-100 bulk cap. It meaningfully enriches parameters beyond the schema's field-level descriptions.

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?

Opens with a specific verb+resource ('Publishes one or many Riddles') and immediately clarifies the inverse mode via publish:false, noting 'there is no unpublish tool.' It distinguishes itself from siblings by name, contrasting its validation output with riddle_builder_validate and its unpublish path with riddle_delete.

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?

Gives explicit routing: use riddle_delete instead when a live Leaderboard blocks unpublish, and clarifies that riddle_builder_validate dry-runs a build config rather than a publish. States the condition (origin.writableByThisKey) under which the tool applies. Nothing is left to inference.

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