clipkit
Server Details
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 15 of 15 tools scored. Lowest: 4/5.
Each tool targets a distinct action and resource (e.g., create_project vs set_project vs load_project; add_element vs edit_element vs delete_element; describe_project vs get_project vs validate_project). There is no ambiguity between tools.
All tool names follow a consistent verb_noun pattern (e.g., add_element, create_project, preview_still, read_docs) using lowercase and underscores. No mixing of styles or vague verbs.
With 15 tools, the set covers project lifecycle operations (creation, modification, validation, preview, asset ingestion, documentation) without being overly bloated or too sparse. Each tool has a clear purpose.
The set covers most editing operations but lacks a direct render_video tool, which is referenced in open_in_editor but not provided. This creates a significant gap in the workflow, as users cannot generate the final video output from the MCP server.
Available Tools
15 toolsadd_elementAdd an element to the current projectAInspect
Append a single element to an existing project — a TWEAK, e.g. dropping in one more caption or shape. By default it is added at the top level; pass parent_id to add it INTO a group (nested). The element is any valid schema element: video, image, text, shape, audio, group, caption, or particles. To create a composition or add several elements at once, build the JSON and use set_project instead. The new element is validated as part of the project as a whole before being added. Call get_schema(element_type) for the exact per-type fields; unrecognized keys are flagged.
| Name | Required | Description | Default |
|---|---|---|---|
| element | Yes | A Clipkit element object. Must include `type`. | |
| parent_id | No | Optional id of a group to add this element INTO (nested). Omit to add at the top level. | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| parent_id | No | |
| element_type | No | |
| added_element_id | No | |
| top_level_element_count | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-read-only and non-destructive. Description adds behavioral context: validation as part of the whole project, flagging of unrecognized keys, and default top-level vs nested behavior. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences with no fluff, front-loaded with main purpose, and efficiently covers key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and nested objects, the description covers effect, default behavior, nesting, validation, error handling, and cross-references to related tools (set_project, get_schema). Output schema exists and need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. Description adds meaning beyond schema: explains parent_id nesting, enumerates valid element types, and recommends get_schema for fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Append a single element to an existing project' with specific verb and resource, and distinguishes this tool from siblings like set_project for multiple elements or compositions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (tweak, adding one element) and when not to (compositions, multiple elements), with alternative set_project mentioned. Also guides to use get_schema for fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_projectCreate a new Clipkit projectAInspect
Create a new, blank Clipkit project with the given dimensions and duration, and return its project_id. Defaults: 1920×1080, 10 seconds, 30 fps, output_format "mp4". Call this first when starting a new video. Pass an existing project_id to reset that project to blank; omit it to start a fresh project (note the returned id for subsequent tools).
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | Composition width in pixels. Default 1920. | |
| height | No | Composition height in pixels. Default 1080. | |
| duration | No | Composition duration in seconds. Default 10. | |
| frame_rate | No | Frame rate. Default 30. | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. | |
| output_dither | No | Anti-banding output dither — DEFAULT ON, leave unset. Pass false for byte-exact undithered output, or { amplitude, pattern } to tune. Stops gradients / soft shadows / blur from showing 8-bit banding; deterministic. | |
| output_format | No | Output container/codec. Default "mp4". | |
| background_color | No | Hex color, e.g. "#000000". |
Output Schema
| Name | Required | Description |
|---|---|---|
| width | No | |
| height | No | |
| duration | No | |
| frame_rate | No | |
| project_id | Yes | Id of the created project — pass to subsequent tools. |
| output_format | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) indicate mutation but non-destructive. The description adds that passing existing project_id resets it to blank, a behavioral trait. It also notes return of project_id. No contradictions, but could mention if reset is irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences, front-loaded with core function and defaults, then usage guidance. Every sentence is informative with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no required ones, and an output schema, the description covers main use cases, defaults, and reset behavior. It could mention relationship to sibling tools (like needing project_id for edit_element) but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying defaults for width, height, duration, frame_rate, output_format, and the dual role of project_id (fresh vs reset). This goes beyond the schema but does not detail all parameters like output_dither.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new blank Clipkit project with given dimensions and duration, returns project_id, and distinguishes between starting fresh and resetting an existing project. It is specific and differentiates from siblings like create_promo and set_project by indicating it should be called first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first when starting a new video' and explains when to omit or pass project_id. It provides clear context but does not explicitly list alternatives or when not to use it, though the 'first' directive implies primary use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_promoCompose a designed promo from prebuilt scenes (one fast option)ADestructiveInspect
Assemble a designed-looking promo/intro/product/data video from the Clipkit pattern library: give an ordered list of SCENES and the words, and it bakes in the camera, glass, lighting, motion blur, timing, and layout, then returns an editor link. This is a FAST option when a conventional promo structure fits — it is NOT the only way to make a video and NOT a default; for anything specific or original, author the JSON yourself and call set_project (the full creative range). When you do use this, MIX scene types to fit the brief and vary the structure — a video can be a single kinetic headline, three title cards, a showcase montage, or a data explainer; you do NOT need a hero or a cta. Scene types: hero (glass-orb logo reveal: wordmark, tagline?), kinetic (letter-fly headline: text, subtitle?), showcase (a screenshot tilted in 3D: screenshot URL), title (full-frame title card: headline, kicker?, subtitle?), cta (closing card with a glass button: wordmark, tagline?, cta), stats (hero numbers: stats[{label,current,previous?}], title?), bars (bar chart: bars[{label,value,previous?}], title?), ranking (top-N list: items[{label,value}], title?), pie (pie cards: cards[{label,value,total,previous?}], title?). The data scenes (stats/bars/ranking/pie) look best with theme "mux".
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | Visual theme. Default "cinematic" (dark, serif, premium). | |
| width | No | Default 1920. | |
| height | No | Default 1080. | |
| scenes | Yes | Ordered scenes; mix types to fit the brief — you do NOT need hero/cta. e.g. a single [{type:"kinetic",text:"…"}], a sequence [{type:"title",headline:"…"},{type:"showcase",screenshot:"…"},{type:"title",headline:"…"}], or a data piece [{type:"ranking",title:"…",items:[…]}] | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. | |
| motion_blur | No | Supersampled motion-blur samples (≥2 enables it — nicer but slower to render). Default off. |
Output Schema
| Name | Required | Description |
|---|---|---|
| width | No | |
| height | No | |
| duration | No | |
| editor_url | No | |
| project_id | Yes | |
| scene_count | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the description adds limited transparency beyond that. It mentions 'bakes in' and 'returns an editor link' but does not detail what gets destroyed or if it overwrites existing projects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first sentence states purpose, then usage guidelines, then a list of scene types. It is informative but could be slightly more concise; still every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of scene types and the existence of an output schema, the description covers the essential aspects: what the tool does, how scenes are structured, and examples of valid inputs. It mentions the returned editor link. The main gap is no detail on error handling or project_id usage, but the output schema likely covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds value by listing scene types with required fields (e.g., 'hero: wordmark, tagline?') and advising that data scenes work best with theme 'mux'. This provides practical guidance beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Assemble a designed-looking promo/intro/product/data video from the Clipkit pattern library' and clearly distinguishes itself from sibling `set_project` by calling itself a 'FAST option' and noting that for specific/original work one should use `set_project`. It also lists the scene types and what they produce.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when a conventional promo structure fits') and when not to use ('for anything specific or original, author the JSON yourself and call set_project'). Also provides examples and encourages mixing scene types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_elementDelete one element by idADestructiveInspect
Delete the element with the given id, anywhere in the tree (including one nested inside a group or its mask) — a tweak to an existing composition. (The project must keep at least one top-level element.)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id of the element to delete. | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| deleted_element_id | Yes | |
| top_level_element_count | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds the tree-scope and the project constraint, providing useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and scope, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive operation and presence of output schema, the description covers the key behavior (deletion, tree scope, constraint) but could mention what happens to related elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add significant meaning to the parameters beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (delete), resource (element), and scope (anywhere in the tree including nested), effectively distinguishing it from sibling tools like add_element and edit_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (to delete an element in the composition) and includes the constraint that at least one top-level element must remain, but does not explicitly compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_projectDescribe the current project in plain languageARead-onlyInspect
Return a compact, human-readable summary of the current project — dimensions, fps, duration, an element breakdown by type, a per-track timeline (paint order low→high), and render-time warnings. Much cheaper to read than get_project's full JSON; use it to orient yourself or sanity-check structure without dumping the whole source.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description reinforces it's a read operation ('cheaper to read'), adding behavioral context like compactness and output contents. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loading purpose and benefits, with no wasted words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one optional param and no output schema, the description fully covers output content and usage context, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with description. The description adds value by explaining when to omit the parameter (single local project), exceeding the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compact, human-readable summary listing specific contents (dimensions, fps, duration, etc.) and distinguishes it from get_project's full JSON, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for orientation or sanity-checking without dumping the full source, and contrasts with get_project as cheaper, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_elementTweak one existing element (merge changed fields)AInspect
Change fields on the element with the given id by merging in a partial element — only the keys you include change. The id may be any element ANYWHERE in the tree, including one nested inside a group (or its mask). Pass a whole nested value (e.g. a new keyframe_animations array) to replace that key; set a key to null to remove it. This is for TWEAKING an existing composition. To create a composition or change many elements at once, edit the JSON and call set_project instead. The result is re-validated before being accepted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id of the element to edit. | |
| patch | Yes | Partial element: the fields to change. Omitted keys are left as-is; a key set to null is removed. | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| element_id | Yes | |
| changed_keys | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses merge semantics, null removal, and that id can be nested. Annotations already indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), so description adds context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with core purpose, followed by operational details and usage guidance. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, output schema present), the description covers purpose, behavior, parameter semantics, and usage boundaries, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond schema: explains that id can target nested elements, and patch supports null to remove keys and nested value replacement. Schema coverage is 100%, but description enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool tweaks an element by merging a partial element. It specifies the verb 'change' and resource 'element', and explicitly distinguishes from sibling tools like set_project for bulk changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says this is for TWEAKING an existing composition, and advises to use set_project for creation or bulk changes. Implies delete_element for deletion, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_projectGet the current Clipkit project JSONARead-onlyInspect
Return the full current Clipkit source as JSON. Use this to inspect the project, pass it to a render pipeline, or compose follow-up edits.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so description adds no extra safety details. It correctly implies read-only behavior but lacks disclosure of any side effects or limitations beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brisk sentences, front-loaded with primary action. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and no output schema, the description sufficiently conveys the tool's purpose and return type (JSON). However, it does not specify the structure or properties of the returned JSON.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter is optional with clear description. The tool description does not add any additional meaning to the parameter beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return the full current Clipkit source as JSON', specifying the verb 'return' and resource 'full current Clipkit source'. It distinguishes from siblings like 'describe_project' by emphasizing full JSON output. Use cases are listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context: 'Use this to inspect the project, pass it to a render pipeline, or compose follow-up edits.' However, it does not explicitly exclude cases or mention alternatives like 'describe_project'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_schemaGet the Clipkit JSON Schema (exact fields)ARead-onlyInspect
Return the authoritative JSON Schema for a Clipkit Source — exact field names, types, and enums, generated from the protocol. Call with no argument for the full Source schema, or with element_type (e.g. "text", "shape", "particles") for just that element's fields (much smaller). Use this when authoring with set_project / add_element so you never guess a field.
| Name | Required | Description | Default |
|---|---|---|---|
| element_type | No | Limit to one element type's fields (e.g. "text"). Omit for the full Source schema (large). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description consistently reinforces. The description adds behavioral context about the two invocation modes (full vs. partial schema) and hints at performance ('much smaller'), going beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and each sentence adds value. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, clear annotations), the description covers purpose, parameter behavior, and use case completely. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the parameter. The description adds mild extra value by repeating the two modes and providing examples, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the authoritative JSON Schema for a Clipkit Source, specifying exact field names, types, and enums. It distinguishes between full schema and per-element schema, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool when authoring with set_project or add_element to avoid guessing fields. Also advises on when to call with no argument versus with element_type, guiding the agent's invocation choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ingest_assetHost a remote image/video/audio so a project can use itAInspect
Fetch a remote media URL (image/video/audio) and HOST it on Clipkit, returning a stable asset_url to put in an element's url. Use this so the project's media survives — the original link may rot, be private, or block hotlinking. Anonymous projects allow up to 5 hosted assets / 100 MB total / 50 MB per file; when the limit is hit, tell the user to open the project (open_in_editor) and sign in to add more. Requires project_id.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A public http(s) URL to an image, video, or audio file. | |
| filename | No | Optional display name for the asset. | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| asset_id | Yes | |
| filename | Yes | |
| asset_url | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false). Description adds useful behavioral details: fetches remote URL, hosts it, returns stable URL, enforces storage limits. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences efficiently covering what, why, limits, workaround, and requirement. No waste; front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and tool complexity, description explains return value (asset_url), limits, and alternative. Could mention error cases but adequate for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds context: project_id is 'required' (clarifying its typical use) and mentions output (asset_url). Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'fetch and host' targeting remote media URL, clearly distinguishing from siblings like add_element or create_project. The purpose is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (to survive link rot/private/hotlinking) and what to do when limits hit (open_in_editor). Does not explicitly state when not to use, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
load_projectLoad a shared project back into the sessionADestructiveInspect
Import a previously shared project as the current project, by its share id or its editor URL (e.g. https://clipkit.dev/editor?id=…), returning its project_id. Use this to continue working on a project the user opened in the editor or shared earlier — the round-trip for open_in_editor. Pass an existing project_id to load into that project; omit it to load into a new one.
| Name | Required | Description | Default |
|---|---|---|---|
| id_or_url | Yes | A share id, or a clipkit.dev/editor?id=… URL. | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| width | No | |
| height | No | |
| duration | No | |
| project_id | Yes | |
| element_count | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds context about loading into current session and returning project_id, but does not elaborate on side effects of overwriting current project. Still provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. First sentence states action and return, second gives usage context with sibling reference, third explains parameter behavior. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (2 params, output schema exists, annotations provided), the description fully covers purpose, usage conditions, parameter semantics, and return value. References sibling tool and explains the round-trip pattern. No gaps 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by clarifying that id_or_url can be a share id or editor URL, and explaining the conditional behavior of project_id (omit for new project, include to load into existing), which goes beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Import' and resource 'shared project', explains two input formats (share id or editor URL), and explicitly positions it as the reverse operation of open_in_editor, distinguishing from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('to continue working on a project the user opened in the editor or shared earlier') and provides alternative references (open_in_editor). Also explains the two usage modes depending on whether project_id is provided or omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
open_in_editorCreate a shareable link that opens the current project in the editorAInspect
Validate the current project and create a link that opens it in the Clipkit web editor, where the user can preview and refine it. This shares the PROJECT (nothing is rendered — that's render_video). Use after composing or editing. Returns a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| editor_url | Yes | |
| project_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining the tool validates the project, creates a link, and does not render (contrasting with render_video). Annotations indicate readOnlyHint=false and destructiveHint=false, and the description aligns with that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each earning its place: action, clarification, usage timing, and return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no nested objects, output schema exists), the description is sufficiently complete. It covers validation, linking, and return type, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (project_id) has 100% schema coverage, so baseline is 3. The description adds extra guidance: 'Omit when working on a single local project,' enhancing the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validate and create a shareable link opening the project in the editor. It specifies the resource (project) and distinguishes from render_video, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use after composing or editing,' providing clear context for usage. While it doesn't list when-not or alternatives beyond render_video, the guidance is sufficient for a focused tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_stillRender one frame of the current project so you can SEE itARead-onlyInspect
Render a single frame of the current project to a PNG and return it as an image you can look at. This is how you check your work — in chat there is no other way to see what a composition actually looks like. Use it liberally: after composing, after edits, and at different times to inspect motion. Stills are FREE (credits are only spent by render_video). Pass time (seconds) to choose the frame; defaults to 0.
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Composition time in seconds to capture. Default 0 (first frame). | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| time | Yes | |
| width | No | |
| height | No | |
| mime_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds that stills are free and that credits are only spent by render_video. It also explains the output is an image, providing full transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core purpose, followed by importance, usage frequency, cost, and parameter details. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for its complexity: covers purpose, usage guidance, behavioral traits, parameter semantics, and cost implications. Output schema exists, so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the parameters: for `time`, it specifies seconds and default 0; for `project_id`, it clarifies omission when working on a single local project. Schema coverage is 100% but description enhances with usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a single frame as a PNG for visual inspection, distinguishing it from video rendering by noting stills are free. It uses a specific verb "render" and resource "single frame", effectively differentiating from sibling tools like edit_element or render_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using the tool liberally after composing, after edits, and at different times to inspect motion. It also distinguishes from render_video by clarifying cost differences, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_docsRead the Clipkit authoring docsARead-onlyInspect
Return a canonical Clipkit doc as text. topic "agents" = the authoring guide (schema cheat sheet, pattern catalog, recipes, guidance — read this BEFORE composing); "protocol" = the formal field spec; "brand" = brand reference. (Same docs offered as MCP resources, exposed as a tool so you can read them directly — resources are not always model-readable.)
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Which doc. Default "agents". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that tool returns text, consistent with readOnlyHint annotation. No contradictions; discloses that same content is available as resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the action and then enumerates topics efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one enum parameter; description fully explains each option and the output format ('as text'). No missing information for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the enum, but description adds contextual details for each value beyond the schema, e.g., 'pattern catalog' for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return a canonical Clipkit doc as text' and explains three topics with specific purpose. Distinct from sibling tools which manipulate projects/elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance per topic (e.g., 'read this BEFORE composing' for agents) and notes this tool is for direct reading when resources may not be model-readable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_projectReplace the entire Clipkit projectADestructiveInspect
Replace the entire project with the given source JSON, returning its project_id. This is the PRIMARY way to build: use it to create a composition or to add/change many elements at once. (To tweak a single element in an existing project, use edit_element / add_element / delete_element instead.) Pass an existing project_id to replace that project; omit it to create a new one (note the returned id). The input is validated against the @clipkit/protocol before being accepted; invalid inputs return an error. Shape: { width, height, duration, frame_rate, output_format, background_color?, fonts?, camera?, lights?, elements:[…] }; every element has a type plus base fields (id, x, y, width, height, time, duration, track, opacity, rotation, animations, keyframe_animations) and type-specific fields. For exact field names + types call get_schema (optionally with an element_type) — the runtime ignores unrecognized keys, and this tool flags any it does not recognize.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | A full Clipkit source object. | |
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| width | No | |
| height | No | |
| duration | No | |
| project_id | Yes | |
| element_count | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, which the description aligns with by saying 'Replace the entire project'. The description adds useful behavioral context: input validation against @clipkit/protocol, error on invalid inputs, return of project_id, and that unrecognized keys are flagged. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence adds value. It is front-loaded with the primary purpose and uses parenthetical guidance and a list format for the shape. A minor improvement could be tightening the element field description, but overall it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object, many siblings, output schema exists), the description is remarkably complete. It covers the main use case, alternatives, input structure, validation behavior, and creation vs. replacement. With an output schema, return values are already documented, and the description adds context about the returned project_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning by detailing the shape of the `source` object: listing fields like width, height, duration, frame_rate, etc., and explaining that elements have a `type` plus base and type-specific fields. It also references get_schema for exact field names, which goes well beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Replace', the resource 'entire project', and the action 'with the given source JSON, returning its project_id'. It distinguishes itself from siblings like edit_element, add_element, and delete_element by noting it is the primary way to build and to add/change many elements at once.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is the PRIMARY way to build: use it to create a composition or to add/change many elements at once.' and provides when-not-to-use guidance: 'To tweak a single element... use edit_element / add_element / delete_element instead.' It also clarifies how to create a new project by omitting project_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_projectValidate the current project (schema + render-time warnings)ARead-onlyInspect
Run the @clipkit/protocol validator against the current project AND surface render-time warnings even when the JSON is valid — things that pass the schema but the runtime will silently drop or clip: emoji / non-ASCII text (the runtime font atlas is ASCII-only), elements that run past the composition end, a missing top-level duration. Run it before you share or render the project. For a fuller timeline read-back, use describe_project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | Which project to act on — the id returned by create_project / set_project / create_promo / load_project. Omit when working on a single local project. |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| width | No | |
| errors | No | |
| height | No | |
| duration | No | |
| warnings | No | |
| error_count | Yes | |
| unknown_keys | No | |
| element_count | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses specific behaviors beyond the readOnlyHint annotation: it lists exact warnings checked (emoji, non-ASCII, elements past end, missing duration). No contradictions with annotations; readOnlyHint is consistent with a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately stating the tool's purpose and key details. No wasted words, and the alternative tool is mentioned efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (as per context signals), the description doesn't need to explain return values. It covers purpose, usage, behavioral details, and distinguishes from a sibling. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter 'project_id' has schema documentation. The description adds context: 'Omit when working on a single local project.' This clarifies usage beyond the schema. Schema coverage is 100%, so a score of 4 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a validator against the current project and surfaces render-time warnings. It specifies exactly what it checks (schema validity, emoji/non-ASCII text, elements past composition end, missing duration) and distinguishes itself from the sibling tool 'describe_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Run it before you share or render the project' and provides an alternative: 'For a fuller timeline read-back, use describe_project.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!