Skip to main content
Glama

Create entity

create_entity

Create ACTOR, PRODUCT, VISUAL_STYLE, or SLIDESHOW_THEME entities for VideoGen, then attach references and use returned entityId in avatar, storyboard, or slideshow generation.

Instructions

Create an ACTOR (character), PRODUCT (product/object), VISUAL_STYLE, or SLIDESHOW_THEME entity. After create, attach at least one reference with add_entity_reference (upload the file first). Slideshow themes may attach an image or a PDF / PowerPoint. Use the returned entityId as actorEntityId on generate_avatar / script_to_video, a product/style reference in storyboard scenes, or slideshowThemeEntityId on slideshow_to_video.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name for the entity.
entityTypeYesACTOR = consistent character; PRODUCT = product/object; VISUAL_STYLE = look/style for generated images; SLIDESHOW_THEME = shared slide design system for a slideshow deck.
descriptionNoOptional longer description.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name.
entityIdYesEntity id (vg_enti_...).
createdAtYesUnix created-at timestamp.
isBuiltInNoTrue for VideoGen catalog entities that cannot be modified.
updatedAtYesUnix updated-at timestamp.
entityTypeYesACTOR, PRODUCT, VISUAL_STYLE, or SLIDESHOW_THEME.
referencesYesAttached reference images.
actorConfigNoVoice/avatar summary for ACTOR entities; null for other types.
descriptionYesDescription (empty when unset).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is covered structurally. The description adds genuinely useful behavior: creation alone is insufficient (a reference must follow), and the type-to-downstream mapping. It stops short of stating idempotency or failure/limit behavior, so not a 5.

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?

Three sentences, zero filler, front-loaded with the create action followed by the required follow-up step and the downstream consumption. Every clause carries distinct operational information.

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?

With an output schema present, return values need not be explained, and the description covers the remaining unknowns: valid types, the mandatory reference attachment, file upload ordering, and where entityId is reused. Nothing an agent needs to call and chain this tool is missing.

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 coverage is 100%, so entityType, name, and description are already documented with rich enum comments. The description still adds value by linking each entity type to the downstream parameter it feeds (actorEntityId, product/style reference, slideshowThemeEntityId), which the schema does not say. Slightly above the baseline for that extra mapping.

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?

Starts with a specific verb+resource ('Create an ACTOR... PRODUCT... VISUAL_STYLE... SLIDESHOW_THEME entity') and enumerates exactly what can be created, distinguishing it from sibling mutation tools like update_entity or archive_entity. An agent immediately knows this is the entity-creation entry point.

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?

Explicitly states the post-create requirement ('attach at least one reference with add_entity_reference (upload the file first)'), names the prerequisite tool and ordering, and spells out where the returned entityId is consumed (generate_avatar, script_to_video, storyboard scenes, slideshow_to_video). This is a full workflow route, not just a hint.

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