Skip to main content
Glama

Read the edit decision list

get_edl
Read-only

Returns the current edit decision list and version. Large timelines support compact indexes, selected sections and pagination, preserving valid JSON rather than returning a truncated document.

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": "get_edl"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
compactNo
sectionsNoUse exact top-level fields: keep, split_keep_boundaries, canvas, captions, music, sfx, volume, frame, inserts, voiceover, effects, overlays, texts, vectors, speed, master, stem_mix, caption_mutes, source_clean, patches; or overview. Feature/tool names are not sections. Read the creative plan with get_edit_plan.
project_idYesExplicit project identifier for this request. The connection's navigation pointer does not select the target.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Required immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess."New value: +"Explicit project identifier for this request. The connection's navigation pointer does not select the target."
  2. Changed1 schema field changed
    • addedInput schema / properties / sections / description
      Added value: +"Use exact top-level fields: keep, split_keep_boundaries, canvas, captions, music, sfx, volume, frame, inserts, voiceover, effects, overlays, texts, vectors, speed, master, stem_mix, caption_mutes, source_clean, patches; or overview. Feature/tool names are not sections. Read the creative plan with get_edit_plan."
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, not idempotent), so the description adds real value beyond them: it discloses that a version is returned alongside the list, that large timelines can be served via compact indexes, section selection and pagination, and notably that responses are always valid JSON rather than truncated. That truncation guarantee is exactly the kind of behavior an agent cannot get from the schema or annotations.

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?

Two sentences, front-loaded with the return value, then the large-timeline strategy. Dense but every clause carries information; the trailing 'preserving valid JSON rather than returning a truncated document' is the only slightly verbose phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing returns — it names the EDL and version and guarantees valid JSON, but says nothing about the document's shape or what a 'version' means for concurrency. For a complex read tool with 5 parameters, that is adequate but leaves gaps.

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

Parameters3/5

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

Schema coverage is only 40%, so the description is expected to compensate. It does explain the intent behind four of five parameters (compact indexes, selected sections, pagination via limit/offset), but gives no format or value guidance for limit/offset or compact, leaving that work to the schema's sections/project_id descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Returns the current edit decision list and version.' An agent can immediately tell this is a read of the EDL document. It stops short of naming a sibling (the get_edit_plan pointer lives only in the schema, not the description), so it is clear but not sibling-differentiated within the description itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the mention of 'large timelines' supporting compact/sections/pagination hints that this tool is intended for big projects, but there is no explicit when-to-use or when-not-to-use guidance against alternatives like get_editorial_map or get_edit_plan. It also does not say whether it must be called before mutation tools.

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.