Skip to main content
Glama

levea-mcp-server

autonomous_edit

PRIMARY EDIT TOOL. Run a natural-language video edit end-to-end. The backend agent plans, executes, verifies, and exports. Accepts anything from a one-liner ("generate 3 viral clips with captions and export") to a multi-paragraph creative brief. Returns the final mp4 URL synchronously when an export is queued. For long renders you may prefer queue_edit + check_job_status.

Input Schema

NameRequiredDescriptionDefault
sceneNoOptional existing scene/timeline state to continue editing (advanced).
assetsNoOptional asset descriptors. Each item: { id?, type: "video"|"image"|"audio", url|src, mimeType?, duration? }.
promptYesNatural-language description of the desired edit or creative brief. The backend planner decomposes it into canonical actions (viral clips, captions, reframe, export, …). Send the user's intent verbatim — do not pre-decompose into multiple calls.
brandIdNoOptional brand-profile id to apply for this call (palette, fonts, logo, voice, gradeBias). Look up ids via list_brand_kits. Overrides project default brand.
core_onlyNoIf true, response carries only rendering-essential scene fields (no debug metadata).
video_urlNoOptional source video URL. Auto-seeded as the starting layer when no scene is provided.
editedPlanNoOptional pre-edited plan object returned by a prior awaiting_approval response.
project_idNoOptional project id for tracking / continuity.
flaggedIssuesNoOptional list of specific user-flagged problems for this run (e.g. ["caption #3 misspelled"]).
workingMemoryNoWorking-memory snapshot returned by a prior call (typically one that returned awaiting_approval). Re-sending resumes that run.
attachedImagesNoOptional base64-encoded reference images the agent should consider while planning.
projectBrandIdNoOptional default brand for the project. Persists; per-call brandId overrides.
captionTemplateModeNoHow to apply captionTemplatePreset.
requirePlanApprovalNoIf true, the agent stops after planning and returns { status: "awaiting_approval", workingMemory, plan } without mutating. Resume by re-calling with the returned workingMemory + an approval prompt ("yes", "approve", "do it").
captionTemplatePresetNoOptional caption template slug to apply when (re)generating captions. One of 41 builtins (hormozi, mrbeast, viral-pop, minimal-pro, karaoke, neon-pop, typewriter, pop-wave, subtitle-bar, creator-box, …) or a user-saved template id from list_caption_templates.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the backend plan/execute/verify/export pipeline and that the final mp4 URL returns synchronously when an export is queued — behavioral facts not in the schema. It omits failure modes, cost/timeout expectations, and reversibility, which keeps it from a 5.

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?

Front-loads 'PRIMARY EDIT TOOL' and the core action, then layers scope, return behavior, and the long-render alternative across four tight sentences with zero waste.

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

Completeness4/5

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

For a 15-param tool with nested objects, no annotations, and no output schema, it covers intent, routing, and synchronous return well, and the schema handles param detail. Minor gaps remain around failure/permission/limit behavior that an agent might want before committing.

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 description coverage is 100%, so the schema already documents all 15 parameters thoroughly. The description reinforces the prompt semantics ('send intent verbatim') but adds little beyond what the schema provides, so baseline 3 is appropriate.

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?

States a specific verb and resource ('run a natural-language video edit end-to-end'), names itself as the PRIMARY EDIT TOOL, and contrasts with queue_edit + check_job_status. An agent can tell exactly what it does and how it differs from siblings.

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?

Explicitly recommends queue_edit + check_job_status for long renders, giving a clear when-to-use alternative. It does not address the autonomous_edit_streaming sibling, leaving one routing decision to inference, but the core guidance is strong.

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.