get_element_schemaReturn the JSON schema for an element type's type_data. Call this before add_elements / update_elements when you don't already know the field shape for the element_type you're placing.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'add' returns required + optional fields; 'update' returns all-optional. | add |
| element_type | Yes | One of: text, callout, rectangle, arrow, blur, spotlight, zoom, image, video, animation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's safety profile is covered. The description adds that it returns 'the JSON schema for an element type's type_data', which is useful behavioral context. However, it doesn't disclose details like response format, error behavior, or rate limits, which are not critical for a simple read-only tool.
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?
The description is two sentences, both front-loaded with the primary action. Every sentence earns its place: the first states the purpose, the second provides usage guidance. No wasted words or redundancy.
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 tool with 2 parameters, no output schema, and no nested objects, the description is fully adequate. It explains the return value (JSON schema), the use case, and the relationship to sibling tools. An agent can confidently select and invoke this tool without additional context.
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% (both parameters fully described with enums and descriptions in the input schema). The description does not add additional meaning beyond what the schema provides. Baseline 3 is appropriate; the description does not need to compensate for missing schema info.
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 clearly states the tool returns a JSON schema for an element type's type_data, with a specific verb ('Return') and resource ('JSON schema for element type's type_data'). It explicitly distinguishes from sibling tools 'add_elements' and 'update_elements' by positioning itself as a prerequisite call.
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?
The description explicitly says 'Call this before add_elements / update_elements when you don't already know the field shape', providing clear context for when to use. It doesn't explicitly state when not to use (e.g., when schema is known) or list alternative tools, but the guidance is sufficient for most agents.
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 clearly distinct purposes, but there is notable overlap between remove_elements and remove_from_project(target='element'), which both remove elements from a clip. This duplication could cause an agent to misselect. Otherwise, tools like add_clips, add_elements, add_audio, and analyze_audio are well-differentiated.
All tools follow a consistent verb_noun pattern (e.g., add_clips, create_project, get_clip, update_elements). There are no camelCase or mixed conventions. Even compound names like voiceover_batch and auto_sync fit the pattern. This makes the tool set predictable for an agent.
With 40 tools, the set is significantly larger than the 3-15 range that typically earns its place. While the domain of video creation is broad, several tools seem redundant (remove_elements vs remove_from_project) or narrowly scoped (get_design_guide, get_element_schema), inflating the count. The number feels heavy for the apparent scope.
The tool surface covers most lifecycle operations: create, read, update, delete for projects, clips, elements, audio, articles, and clueprints. Minor gaps exist, such as no explicit tool to delete a voiceover (only mute via update_clips) and no folder management beyond listing. Overall, agents can accomplish full workflows with few workarounds.