Skip to main content
Glama
Sign In

zipir

by com.zipirapp
OverviewDiscussionsAdmin

Edit one scene of a lesson

edit_lesson

Change one scene of a lesson (rewrite, shorten, retitle or restyle it); no render starts

The panel's own frame edit reached with an API key: the system proposes a patch to one scene and the source-quote check still decides -- a sentence the document does not support is refused. Name the target with scene_index or cue_index, exactly one of them (a cue is a scene's caption, so it names that scene). The call starts no render; the change is prepared in the background and accepting it stays the owner's step in the panel. Nothing is charged here: minutes are held when the video is rendered again (rerender).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "operation": "<operation>"
    },
    "name": "edit_lesson"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesid
cue_indexNo0-based position of the spoken caption; a caption belongs to a scene, so it names that scene. Exactly one of scene_index / cue_index.
operationYesrewrite: say it again in the document's own words. shorten: the same point in fewer words. retitle: a new scene title. style: change how the scene looks, not what it says.
instructionNoWhat exactly should change, in one or two sentences. The source check still applies: the document must support the new sentence.
scene_indexNo0-based position of the scene in the storyboard. Exactly one of scene_index / cue_index.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare mutation-without-destruction; the description adds genuinely new behavior: a source-quote check can refuse an unsupported sentence, the change is staged in the background rather than applied, and no minutes are charged until rerender. These are non-obvious consequences an agent could not infer from readOnlyHint=false or destructiveHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first clause, which is good, but the second sentence is dense and awkwardly built ("The panel's own frame edit reached with an API key:..."), and the no-render point is stated twice. It is readable but carries avoidable redundancy.

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

Completeness4/5

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

For a five-parameter mutation with no output schema, the definition covers refusal conditions, staging behavior, and billing well. The main remaining gap is that it never says what the call returns (a patch handle, a preview, a status), forcing the agent to discover the response shape at runtime.

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 description coverage is 100%, so the schema already documents every parameter including the operation enum and the mutual exclusivity of scene_index/cue_index. The description restates the targeting rule and explains that a cue names its scene, which is helpful but largely duplicative. It adds no new meaning for id or instruction beyond what the schema states.

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?

"Change one scene of a lesson (rewrite, shorten, retitle or restyle it)" gives a specific verb plus a bounded resource, and the parenthetical enumerates the four supported operations. The clause "no render starts" separates it from rerender, so an agent can pick between them without opening schemas.

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 makes the usage condition clear: this prepares a scene-level patch, and accepting it remains the owner's step in the panel, which tells the agent not to expect the edit to be live. It also explains the targeting rule (exactly one of scene_index/cue_index). It never states exclusions for the neighbouring tools such as create_lesson or approve_lesson, so the routing guidance stops short of explicit alternatives.

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

All zipir toolsInspect
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.

Resources