Skip to main content
Glama

Get actor B-roll default

get_actor_defaults
Read-only

Retrieve an actor's saved B-roll default to know if people, hands, or the actor are included. Clarifies override rules for video generation.

Instructions

Read this account actor's saved B-roll default. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actor_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.20.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already mark readOnlyHint and non-destructive, and the description enriches them by defining the policy values (anyone/no_actor/no_people), stating the setting only affects B-roll and not actor-only videos, and noting that run override wins with no_people as fallback. No contradiction with annotations.

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?

The purpose sentence is front-loaded and the remaining sentences explain policy semantics and precedence with little fluff. It is slightly dense—'Segmented media generation is closed' is cryptic—but each sentence contributes useful context.

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?

For a one-parameter read tool with a readOnly annotation, the description covers policy meaning, scope, and fallback behavior. However, with no output schema, it does not mention return format or what happens when no default is set, leaving some ambiguity about the tool's output.

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?

The schema provides only actor_id as a required string with no description, so coverage is 0%. The description refers to 'this account actor's' default, which implies actor_id identifies an account actor, but it does not elaborate on format, ownership validation, or the exact role of the parameter beyond that.

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 'Read this account actor's saved B-roll default,' which names a specific verb, resource, and scope. It clearly differentiates from the write-oriented sibling set_actor_defaults and from other actor tools by focusing on the saved B-roll policy.

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?

It gives clear context for when this tool matters: reading the saved B-roll default for an account actor and understanding that run overrides take precedence. It does not explicitly name alternatives like get_run or set_actor_defaults, but the read-vs-write and override semantics make the intended use obvious.

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