Skip to main content
Glama

Set actor B-roll default

set_actor_defaults
Idempotent

Save an actor's default B-roll policy without spending credits, so Clipwright applies your chosen rules for anyone, no actor, or no people.

Instructions

Save this account actor's B-roll default without spending credits; broll_policy says what each value does.

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": {
      "actor_id": "<actor_id>",
      "broll_policy": "<broll_policy>"
    },
    "name": "set_actor_defaults"
  }
}

Input Schema

NameRequiredDescriptionDefault
actor_idYes
broll_policyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.45.0
    • removedInput schema / properties / broll_policy / description
      Removed value: -"Saved policy for B-roll: anyone allows people including the actor; no_actor excludes the actor; no_people excludes all people, including hands."
  2. Changed2 schema fields changedv0.39.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / broll_policy / description
      Previous value: -"Saved policy for B-roll: anyone allows people including the actor; no_actor excludes the actor; no_people excludes all people, including hands. Segmented media generation is closed. This setting is stored only and has no effect on actor-only videos. Run override wins over the account actor default; otherwise no_people."New value: +"Saved policy for B-roll: anyone allows people including the actor; no_actor excludes the actor; no_people excludes all people, including hands."
  3. First observedv0.20.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false; the description adds a genuinely useful trait beyond those, namely that the call spends no credits. However, it does not say that an existing default is overwritten or that any prior value is lost, and its pointer for broll_policy value meanings is unfulfilled.

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?

A single tight sentence with the action and the cost caveat front-loaded, which is efficient. The trailing clause about broll_policy is the only wasted text, since it references documentation that is not present.

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

Completeness2/5

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

This is a mutation tool with no output schema, zero parameter description coverage, and an unexplained enum, so the description needs to do more than one sentence. It omits what the call returns, whether the change is immediate or scoped to one account, and any meaning for the three policy values, leaving the agent under-equipped to call it correctly.

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%, so the description carries the full burden, and it largely fails: actor_id is only implied by "this account actor's," and "broll_policy says what each value does" promises meaning that does not exist in the schema, which only lists the enum values anyone/no_actor/no_people. The agent is left unable to distinguish the practical effect of no_actor versus no_people.

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?

"Save this account actor's B-roll default" names a specific verb (save/set) and resource (an account actor's B-roll default), so an agent can tell it apart from the sibling get_actor_defaults by the write framing. It stops short of explicitly naming that read counterpart, so the differentiation relies on inference from "Save".

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit when-to-use or when-not guidance and never mentions get_actor_defaults as the read alternative. "Without spending credits" is the only contextual cue, which tells the agent this call is free but does not say under what circumstances to set a default versus just reading it.

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