Skip to main content
Glama

Remove element, group or audio track

remove_from_project
Destructive

Remove an element, a group or an audio track from a project.

  • target="element": removes an element (requires element_id, or element_ids for several). clip_index is optional — the element is located by id; pass it only as a hint

  • target="group": removes a GROUP node (requires clip_index + group_id). By default its children survive — they rise to the removed group's own parent, which for a top-level group is the clip root. Pass keep_children=false to delete the whole subtree instead, every nested group and every element inside it.

  • target="audio": removes a music/SFX track (requires music_id — returned by add_audio)

Concurrency: target='element' is element-scoped (conflict domain: the individual element) — parallel-safe with other element edits on different elements, same as remove_elements. target='audio' is a whole-project mutation — serialize it against any other mutation on the same project_id. (Mutations to different projects run in parallel freely.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYesWhat to remove: 'element', 'group' or 'audio'
group_idNoGroup ID to remove (required for target='group')
music_idNoMusic/SFX track ID to remove (required for target='audio')
clip_indexNoZero-based clip index. Required for target='group'; for target='element' an optional hint — the element is found by id either way
element_idNoElement ID to remove (target='element'; or use element_ids)
project_idYesThe project ID
element_idsNoSeveral element IDs to remove (target='element'). Removed one at a time, so a failure part-way leaves the earlier ones removed; retrying the same list is safe — ids already gone come back as already_absent. For a large batch prefer remove_elements, which lands in one save
keep_childrenNotarget='group' only. Omit/true ungroups: children rise to the removed group's own parent. false deletes the whole subtree.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / clip_index / description
      Previous value: -"Zero-based clip index (required for target='element')"New value: +"Zero-based clip index. Required for target='group'; for target='element' an optional hint — the element is found by id either way"
    • changedInput schema / properties / element_id / description
      Previous value: -"Element ID to remove (required for target='element')"New value: +"Element ID to remove (target='element'; or use element_ids)"
    • addedInput schema / properties / element_ids
      Added value: +{
      +  "description": "Several element IDs to remove (target='element'). Removed one at a time, so a failure part-way leaves the earlier ones removed; retrying the same list is safe — ids already gone come back as already_absent. For a large batch prefer remove_elements, which lands in one save",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. 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",
      -  "target",
      -  "context",
      -  "llm_model"
      -]New value: +[
      +  "project_id",
      +  "target"
      +]
  3. 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",
      -  "target"
      -]New value: +[
      +  "project_id",
      +  "target",
      +  "context",
      +  "llm_model"
      +]
  4. Changed3 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
    • addedInput schema / properties / clip_index / maximum
      Added value: +9007199254740991
  5. Changed4 schema fields changed
    • addedInput schema / properties / group_id
      Added value: +{
      +  "description": "Group ID to remove (required for target='group')",
      +  "type": "string"
      +}
    • addedInput schema / properties / keep_children
      Added value: +{
      +  "description": "target='group' only. Omit/true ungroups: children rise to the removed group's own parent. false deletes the whole subtree.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / target / description
      Previous value: -"What to remove: 'element' or 'audio'"New value: +"What to remove: 'element', 'group' or 'audio'"
    • changedInput schema / properties / target / enum
      Previous value: -[
      -  "element",
      -  "audio"
      -]New value: +[
      +  "element",
      +  "group",
      +  "audio"
      +]
  6. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Even though destructiveHint=true already signals mutation, the description adds rich behavioral context: grouping children survive by default, keep_children=false deletes the whole subtree, element_ids are removed one at a time with safe retries, and audio removal is a whole-project mutation. This goes far beyond the annotations.

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?

The description is structured with bullet-like target sections and a concurrency paragraph. It is dense but not bloated; every sentence carries meaningful operational or safety information. The upfront summary is immediately followed by mode-specific details.

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?

The description covers all three removal modes, required and optional parameters, default behavior, failure semantics, concurrency constraints, and when to prefer a sibling tool. Given there is no output schema, the lack of return-value detail is not a completeness gap.

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 a baseline of 3 applies. The description still adds meaning by clarifying the role of clip_index as an optional hint for element, a requirement for group, and explaining the default behavior of keep_children. It also frames element_ids versus element_id usage clearly, though much is repeated from the schema.

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 opens with a clear, specific statement: 'Remove an element, a group or an audio track from a project.' It identifies the exact verb, resource types, and scope. It further differentiates from the sibling tool remove_elements by recommending it for large batches.

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?

The description provides explicit when-to-use guidance per target mode, listing required parameters for each. It also names an alternative tool (remove_elements) for large batches and gives concurrency rules for when parallel use is safe versus serialized.

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.