Skip to main content
Glama
calebn

Podcast MCP

by calebn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

history_undo

Revert the last timeline, transcript, or settings change in a podcast project. Supply the expected head ID to undo only the reviewed revision and prevent overwriting newer edits.

Instructions

Undo the last project mutation (timeline, transcript, or settings).

Pass expected_head_id (history_status_tool's head_id) to undo only the change you looked at: if another edit landed since, the call refuses with error_code history_stale and nothing changes.

Input Schema

NameRequiredDescriptionDefault
rerenderNo
project_pathNo
expected_head_idNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.1
    • addedInput schema / properties / expected_head_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Expected Head Id"
+}
    • 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"
    • removedInput schema / required
      Removed value: -[
-  "project_path"
-]
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the whole burden and does disclose real behavior: a conditional refusal (history_stale) and atomicity ("nothing changes") when another edit landed since the observed head. It omits a few behavioral facts an agent might want — whether the undo is itself reversible via history_redo, and any permission/project-state prerequisites.

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?

Two tight sentences: the core action first, then the concurrency-safety mechanism. No restatement of the name or title, no filler.

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 no explanation, and the head_id mechanism is well covered. However, for a mutation tool with zero annotations and 0% schema description coverage, leaving rerender and project_path entirely undefined is a meaningful completeness gap.

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?

Schema coverage is 0%, so the description must compensate, and it only explains one of three parameters (expected_head_id, including its provenance and staleness semantics). The rerender and project_path parameters carry no meaning anywhere, leaving a partial gap.

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?

States a specific verb and resource ("Undo the last project mutation") and enumerates the mutation domains it covers (timeline, transcript, or settings). Within a large history family (history_redo, history_list, history_goto_tool, history_diff_tool), the inversion semantics make this tool's role unambiguous without opening any 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?

Gives a concrete usage rule: pass expected_head_id (sourced from history_status_tool's head_id) when you want to undo only the change you inspected, and explains what happens otherwise. It lacks an explicit "use history_redo instead / use history_goto_tool when..." exclusion, so it stops short of full when-not coverage.

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