Skip to main content
Glama

Update project

update_project

Update a project's metadata: rename, change description, move to a different folder, or change aspect ratio.

Only fields you provide are changed. To move a project to the workspace root, pass folder_id="" (empty string).

Aspect ratio: pass any "W:H" (positive integers). The canvas is fit inside 1920×1080 keeping the ratio, so element pixel coordinates use the resulting canvas. Common values:

  • "16:9" → 1920×1080 (landscape, YouTube/web — default)

  • "9:16" → 608×1080 (portrait — TikTok/Reels/Shorts)

  • "1:1" → 1080×1080 (square — Instagram feed)

  • "3:4" → 810×1080 (portrait card)

  • "4:5" → 864×1080 (portrait — Instagram feed)

Element coordinates are stored as fractions of the canvas, so existing elements reflow to the new canvas automatically — no element coordinates are rewritten.

Concurrency: whole-project mutation (conflict domain: the entire project) — serialize. Do not run it in parallel with ANY other mutation on the same project_id, including element/voiceover edits; run them one at a time. (Mutations to different projects run in parallel freely.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoNew project title
folder_idNoNew folder ID. Pass '' (empty string) to move to workspace root.
project_idYesThe project ID to update
descriptionNoNew description
aspect_ratioNoNew aspect ratio as 'W:H' (positive integers). Common: '16:9' landscape, '9:16'/'4:5'/'3:4' portrait, '1:1' square.

TDQS

A4.8/5.0
Behavior5/5

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

Disclosed beyond annotations: partial update (only provided fields change), aspect ratio conversion to canvas (1920×1080 fit), element coordinates reflow automatically, and whole-project mutation conflict domain. Annotations only provide readOnlyHint=false and destructiveHint=false, so description adds critical behavioral context.

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?

Well-structured with a summary sentence followed by parameter details and behavioral notes. Not overly verbose, though the aspect ratio examples could be shortened. Still efficiently communicates essential 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?

Given no output schema, the description covers expected behavior comprehensively: partial update, parameter semantics, effect on canvas and coordinates, concurrency constraints. No missing information for an agent to invoke correctly.

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%, but description adds value: explains aspect ratio format with common examples and canvas sizing, clarifies folder_id empty string for root, and notes element coordinates are fractions that reflow. Slightly redundant with schema but enriches understanding.

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 clearly states 'Update a project's metadata' and lists specific operations (rename, change description, move to folder, change aspect ratio). It distinguishes from sibling tools like create_project, duplicate_project, and get_project by focusing on modifications.

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 instructs when to use: 'Only fields you provide are changed' and how to move to root with empty string. Provides concurrency rules: 'Do not run it in parallel with ANY other mutation on the same project_id' and allows parallel mutations on different projects.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness4/5

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.