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="" (or "root").

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.

Brand kit: brand_kit_id sets the kit this project is built with (an id from find(type='brand_kits')); 'default' makes it follow the workspace default kit; 'none' takes the kit off, so the project is made without one. It changes the kit get_design_guide({project_id}) returns; elements already placed keep their colors, fonts and logos until you edit them. The reply's brand_kit is {id, name, follows_default}, or null with no_kit true when the project has no kit (null without no_kit: the workspace has no kit). Only workspace editors and admins can change it.

Tags: add_tags / remove_tags change the project's tags (the home page Tags menu and filter), by NAME. Adding a name the workspace doesn't have creates it; existing names match ignoring case. List them with find(type='tags'). Only workspace editors and admins can change tags. To tag many projects, loop update_project over their ids in run_script. When tags are given, the reply also has tags (the project's full list after the change), created_tags and not_found_tags (remove_tags names the workspace doesn't have).

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.)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "update_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNoNew project title
add_tagsNoTag names to add; missing tags are created.
folder_idNoNew folder ID. Pass '' (empty string) to move to workspace root.
project_idYesThe project ID to update
descriptionNoNew description
remove_tagsNoTag names to remove.
aspect_ratioNoNew aspect ratio as 'W:H' (positive integers). Common: '16:9' landscape, '9:16'/'4:5'/'3:4' portrait, '1:1' square.
brand_kit_idNoBrand kit for this project: an id from find(type='brand_kits'), 'default' to follow the workspace default kit, or 'none' for no brand kit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / brand_kit_id / description
      Previous value: -"Brand kit for this project: an id from find(type='brand_kits'), or 'default' to follow the workspace default kit."New value: +"Brand kit for this project: an id from find(type='brand_kits'), 'default' to follow the workspace default kit, or 'none' for no brand kit."
  2. Changed1 schema field changed
    • addedInput schema / properties / brand_kit_id
      Added value: +{
      +  "description": "Brand kit for this project: an id from find(type='brand_kits'), or 'default' to follow the workspace default kit.",
      +  "minLength": 1,
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / add_tags
      Added value: +{
      +  "description": "Tag names to add; missing tags are created.",
      +  "items": {
      +    "maxLength": 40,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / remove_tags
      Added value: +{
      +  "description": "Tag names to remove.",
      +  "items": {
      +    "maxLength": 40,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  4. Changed4 schema fields changed
    • removedInput schema / properties / context
      Removed value: -{
      -  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
      -  "type": "string"
      -}
    • removedInput schema / properties / conversation_id
      Removed value: -{
      -  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
      -  "type": "string"
      -}
    • removedInput schema / properties / llm_model
      Removed value: -{
      -  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "project_id",
      -  "context",
      -  "llm_model"
      -]New value: +[
      +  "project_id"
      +]
  5. Changed4 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
      +  "type": "string"
      +}
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
      +  "type": "string"
      +}
    • addedInput schema / properties / llm_model
      Added value: +{
      +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "project_id"
      -]New value: +[
      +  "project_id",
      +  "context",
      +  "llm_model"
      +]
  6. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  7. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive, closed-world write; the description goes far beyond that with partial-update semantics ('only fields you provide are changed'), permission gates (workspace editors/admins for brand kit and tags), the concurrency conflict domain, and the fact that existing element coordinates are not rewritten but reflow. It even discloses reply payload shapes (brand_kit, tags, created_tags, not_found_tags) and the subtle null vs. null+no_kit distinction.

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?

Front-loaded with the core action, then organized into labeled blocks (aspect ratio, brand kit, tags, concurrency), which makes the density navigable. It is on the long side and the aspect-ratio table partly duplicates the schema's own common-value hints, so it is not maximally tight, but no sentence is genuinely wasted.

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?

For an 8-parameter mutation with no output schema, the description covers side effects (tag auto-creation, canvas reflow), permissions, serialization rules, and return-value fields — precisely the gaps structured data leaves open. An agent has everything needed to call this safely on the first attempt.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description meaningfully enriches nearly every parameter: folder_id sentinel '', brand_kit_id 'default'/'none' semantics and its effect on get_design_guide, case-insensitive tag matching with auto-creation, and a full W:H to canvas pixel mapping table. This is real added meaning, not schema restatement.

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?

First sentence names a specific verb and resource and enumerates the mutable surface: rename, description, folder move, aspect ratio. Later paragraphs add brand kit and tags, so an agent can distinguish this from siblings like update_elements, update_clips, and duplicate_project without opening a schema.

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?

Gives concrete routing hints — use find(type='brand_kits') for kit ids, find(type='tags') to list tags, loop update_project inside run_script to tag many projects — and states a hard operating constraint: never run in parallel with any other mutation on the same project_id. What's missing is an explicit statement of when to prefer update_elements/update_clips/update_audio over this tool when a change touches both metadata and content.

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.