Skip to main content
Glama
calebn
by calebn

apply_suggested_actions_tool

Apply all pending podcast sound suggestions in one undo step, including cut, shorten, lower, or leave actions. Override audio checks or revise one decision without undoing the batch.

Instructions

Apply every pending sound's own suggested action in one undo step.

Each tighten proposal carries a label and a suggested_action (propose_edits shows them). This applies all of them, or only ids: cut and shorten cut (a cut held by the automatic audio checks stays pending and is named in held), lower turns a laugh down while another speaker talks over it (otherwise it is left), leave dismisses the proposal and keeps the audio. overrides maps a decision id to another action for that sound. Returns applied by action, cut_over_speaker, held (ids still pending) and a summary sentence. When the user says to apply the held ones anyway, repeat with override_audio_checks=true (recorded in History and the edit log).

To change one sound after the batch (say a cut to leave) without undoing the rest, call again with revise=true and overrides={id: action} and no ids: it steps back to before the latest batch (which must still be the latest edit) and applies it again with that change, as one undo step. Otherwise it refuses with no_suggested_batch_to_revise.

Input Schema

NameRequiredDescriptionDefault
idsNo
reviseNo
overridesNo
project_pathNo
override_audio_checksNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains one-undo-step semantics, how cut/shorten/lower/leave are handled, held audio-check behavior, history/edit-log recording, and revise rollback behavior. It also names returned fields and a refusal case.

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?

The description is long but appropriately dense for a complex mutation tool. The key operation is front-loaded in the first sentence, and subsequent paragraphs are organized around batch behavior, override behavior, and revise behavior with no obvious filler.

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 complex apply tool with five parameters and an output schema, the description is complete enough: it covers batch application, held items, overrides, revise semantics, refusal behavior, and the returned summary fields. The only minor omission is project_path, but the overall operational context is fully supplied.

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 description coverage is 0%, so the description must compensate. It explains ids, overrides, revise, and override_audio_checks well, including action and decision-id semantics, but project_path is never mentioned, leaving one parameter undocumented.

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 resource: applying every pending sound's own suggested action in one undo step. It clearly distinguishes this from propose_edits by referencing where the suggestions come from and explains the batch-apply scope.

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?

It gives explicit when-to-use guidance: apply all pending actions, apply only selected ids, handle held cuts with override_audio_checks, and revise a batch with revise=true and overrides. It also states the refusal condition no_suggested_batch_to_revise, leaving little ambiguity for an agent.

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