get_scene_assetsGet one scene with its shots, characters, locations and continuity references.
| Name | Required | Description | Default |
|---|---|---|---|
| episode_id | Yes | Episode id. | |
| project_id | Yes | Project id. | |
| scene_number | Yes | Scene number. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation. The description adds useful context about the returned composition (shots, characters, locations, continuity references), but does not disclose any additional behavioral traits such as aggregation behavior, response shape, or potential size/performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states exactly what the tool returns with no filler or redundancy. Every part of the sentence earns its place by clarifying the resource and its included associations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three required parameters and no output schema, the description adequately conveys what is returned. It could be more complete by noting any limitations or exactly how the related assets are represented, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a basic description ('Project id.', 'Episode id.', 'Scene number.'). The description adds no meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('one scene') while enumerating what is included: shots, characters, locations, and continuity references. This distinguishes it from sibling tools like get_episode_shots or get_character by indicating it returns a scene plus its related assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions or name any sibling tools, so an agent must infer when this is the right choice among many similar getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clear, distinct purposes, but some overlap exists between get_episode_shots and list_episode_segments, and get_episode_editor vs get_episode could be confused. Overall, the generate/get/list/update families are reasonably distinguishable.
The verb_noun pattern is consistently applied across generate_, get_, list_, and update_ tools. Minor deviations like get_episode_editor (which returns a tree rather than an editor) and get_asset_library (rather than list_assets) prevent a perfect score.
With exactly 25 tools, this exceeds the 'too many' threshold of 25+ in the calibration. While the domain is complex, the count feels heavy, especially with many near-duplicate get/list variants.
The tool surface is read- and generation-heavy but lacks update operations for characters, episodes, and projects, and has no delete operations at all. This creates notable gaps in lifecycle management, though the existing read/generate coverage is substantial.