Skip to main content
Glama
calebn

Podcast MCP

by calebn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

publish_review_version_tool

Freeze the current premix or mastered mix as a review version so comments get stamped with that version ID. Refuses if no mix, stale premix, or master isn't from current premix.

Instructions

Freeze the current premix/mastered mix as a review version under artifacts/review/.

Comments created while a version is active stamp review_version_id. prefer: "premix" (default) or "mastered". Refuses a project with no mix yet (code no_mix: Refresh first), a premix that's stale vs the project (Refresh first) or a master not mastered from the current premix (export first).

Input Schema

NameRequiredDescriptionDefault
labelYes
preferNopremix
set_activeNo
project_pathNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.1
    • addedInput schema / properties / project_path / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / project_path / default
      Added value: +null
    • removedInput schema / properties / project_path / type
      Removed value: -"string"
    • changedInput schema / required
      Previous value: -[
-  "project_path",
-  "label"
-]New value: +[
+  "label"
+]
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it does disclose meaningful behavior: it creates an artifact under artifacts/review/, comments made while a version is active get stamped with review_version_id, and it refuses in three named failure states. It omits what 'set_active' does, whether repeated calls overwrite, and whether the action is reversible.

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 the core action, then the comment side effect, then the refusal contract. Line breaks fall mid-sentence in the refusal paragraph, which slightly hurts scannability, but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and refusal behavior is well covered. However, for a mutation tool with zero annotations and 0% schema coverage, the semantics of set_active and project_path are missing, leaving the definition incomplete for correct invocation.

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

Parameters2/5

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

Schema description coverage is 0% and the schema gives no per-property detail. The description only explains 'prefer' (premix default or mastered); 'label', 'set_active', and 'project_path' remain completely undocumented, so three of four parameters rely on inference.

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 ('Freeze') and resource ('current premix/mastered mix as a review version') with an explicit storage location (artifacts/review/). It is clearly distinguishable from the adjacent list_review_versions_tool and set_active_review_version_tool, though it never names them directly.

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?

Provides explicit when-not conditions with actionable recovery steps and error codes (no_mix, stale premix, master not mastered from current premix). It also notes the default for 'prefer', but does not route the agent to an alternative sibling when the call is refused beyond 'Refresh/export first'.

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

Deploy Server

Other Tools