Goodeye

publish_template_version

Publish the latest version of your skill as a new public template version.

First publish creates the template (slug reused from the skill). Each call appends a monotonic version. Requires a claimed handle. Bundle a 'demo/README.md' writeup with images referenced by relative path inside 'demo/' to render a visual demo on the public template page.

Publishing makes the template's verifier definitions public: anyone who views the template (including anonymous readers) can read each verifier's criterion and calibration examples. Publishing is hard-blocked if a verifier definition contains a secret or credential, and flagged if it appears to contain private data. When the template references verifiers, the response includes a 'verifier_exposure_notice' restating this.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`skill_id`	Yes	The skill to act on, identified by its UUID, slug, or name.
`release_notes`	No	Optional notes describing what changed in this published version.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedJul 18, 2026

addedInput schema / properties / skill_id

Added value: +{
+  "description": "The skill to act on, identified by its UUID, slug, or name.",
+  "type": "string"
+}

removedInput schema / properties / workflow_id

Removed value: -{
-  "description": "The workflow to act on, identified by its UUID, slug, or name.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "workflow_id"
-]New value: +[
+  "skill_id"
+]

First observedJun 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The annotation hints are all false/neutralressive, so the description carries the behavioral disclosure burden. It explains side effects clearly: publishing makes verifier definitions public, a hard block occurs on secrets/credentials, private data triggers a warning flag, and the response includes a verifier_exposure_notice when verifiers are referenced. This is far beyond the annotations and highly relevant for an agent deciding to publish.

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?

Well structured, front-loaded with core purpose, then behavior; no redundant sentences. Each clause carries unique info: versioning, prereq, demo doc, privacy side effects, blocking rule, response field.

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?

Covers the non-obvious aspects an agent must know: template creation on first publish, monotonic versioning, claimed-handle requirement, verifier exposure/privacy implications, blocked vs flagged states, and the response notice field. Nothing critical appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters are already fully described in the input schema (100% coverage), so the description is not required to re-explain them. It adds a context-level prerequisite (claimed handle) but does not deepen the parameter definitions themselves. Baseline 3 is appropriate.

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 specific verb and object: 'Publish the latest version of your skill as a new public template version.' It clarifies the key semantic point that the first publish creates the template and each subsequent call appends a version, which fully disambiguates the tool's purpose and scope.

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 context: when to publish, that a claimed handle is required, and what happens on first vs. subsequent publishes. It doesn't name alternatives like unpublish_template_version, but the unique publish action is unambiguous, and the prerequisite and sequence guidance is enough for an agent to decide when to call it.

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

All Goodeye 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.