Build and edit AI videos on Klox canvases: script, storyboard, shots and final cut.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 9 tools
Each tool has a clearly distinct purpose: workflow creation/listing/reading, workflow editing, capability discovery, upload preparation/completion, node generation, and task polling. The descriptions explicitly clarify boundaries, such as apply_workflow_change never starting generation and run_node requiring saved configs. No overlapping tools would likely cause misselection.
All tools use lower snake_case with predictable verb_noun or verb_noun_noun patterns. The convention is consistent throughout: apply_workflow_change, complete_upload, create_workflow, get_capabilities, get_task, get_workflow, list_workflows, prepare_upload, run_node. There is no mixing of camelCase or vague verb styles.
Nine tools is well-scoped for a workflow/canvas generation server. Core operations are covered without evident redundancy or bloat. Each tool appears to earn its place in the lifecycle.
The surface covers workflow creation, retrieval, listing, editing, capability discovery, upload flow, node generation, and task status. Minor gaps exist, such as no explicit delete_workflow or task cancellation tool. These are workable limitations rather than severe omissions for the apparent core workflows.
Add, update, connect, place and delete nodes and edges in one all-or-nothing edit. New nodes get a localId you can reference from connections and placements in the same request; the response maps each localId to its node id. Connections only give from, to and targetHandle. Never starts generation.
| Name | Required | Description | Default |
|---|---|---|---|
| addNodes | No | ||
| placements | No | ||
| workflowId | Yes | ||
| connections | No | ||
| updateNodes | No | ||
| addFileNodes | No | File nodes for files finished with complete_upload | |
| deleteEdgeIds | No | ||
| deleteNodeIds | No | ||
| expectedRevision | Yes | revision from the latest get_workflow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely new context: the all-or-nothing atomicity, that no generation is triggered, and that the response maps localId to node id. It does not cover permission needs or revision-conflict behavior.
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?
Four tightly packed sentences, front-loaded with the core operation and followed by the exact referencing mechanics an agent needs. No filler or repetition of the name.
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 9-parameter mutation tool with no output schema, the description covers the essential mechanics: atomicity, localId resolution, and the response mapping. It omits revision-conflict handling and the meaning of expectedRevision, but the schema supplies that for the required parameter.
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 only 22%, so the description has to compensate, and it does for the hardest parts: it defines localId, states that connections carry only from/to/targetHandle, and explains placements reference localIds. It leaves other parameters (updateNodes, deleteNodeIds, addFileNodes) to 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?
States a specific verb set (add, update, connect, place, delete) over concrete resources (nodes and edges), and names the transaction model (one all-or-nothing edit). An agent can tell this apart from run_node because the description explicitly says it never starts generation.
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 the key usage rule that this is a pure edit operation ('Never starts generation'), which routes the agent away from run_node. It also explains how newly added nodes are referenced (localId) in the same request. It does not name alternative tools explicitly, so it falls short of a full when/when-not framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finish an upload after the PUT succeeded. Returns the file’s trusted type, size and media duration.
| Name | Required | Description | Default |
|---|---|---|---|
| fileKey | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, non-destructive behavior, so the safety profile is covered. The description usefully adds the return payload (trusted type, size, media duration), but it does not explain what happens on a repeat call even though idempotentHint=false makes that a real concern, nor any auth/error conditions.
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 short sentences, zero filler, with the precondition front-loaded before the return description. Every clause earns its place.
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 one-param mutation tool with annotations and no output schema, the description covers the trigger and return values reasonably well. The gap is the undocumented fileKey parameter, which is the one thing an agent must supply, so it is not fully 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?
With a single parameter at 0% schema description coverage, the description must explain fileKey and it does not name it at all. Only the indirect phrase "after the PUT succeeded" hints at where the key comes from; the format and source are left to inference.
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?
States a specific verb+resource (complete/finish an upload) and adds a precondition ("after the PUT succeeded") that pins the exact lifecycle stage. It does not explicitly name the paired sibling prepare_upload, but the name and phrasing make the pairing obvious enough to distinguish it from the other tools.
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?
"Finish an upload after the PUT succeeded" gives a clear trigger condition for when to call it, which is more than most definitions offer. There is no explicit when-not or named alternative, but the precondition carries the routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an empty workflow (canvas). Retrying with the same idempotencyKey returns the same workflow instead of creating another.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| idempotencyKey | Yes | Client-chosen key identifying this request. Retry with the same key; a new request needs a new key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds concrete semantics for that idempotency (same key returns the same workflow rather than a duplicate) and notes the created object is empty, which is real added value beyond the annotation flags.
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 short sentences, front-loaded with the core action and immediately followed by the one non-obvious behavioral clause. No waste.
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 2-param creation tool with no output schema, the description covers what is created (empty workflow) and how retries behave. It could say more about the title parameter or what the returned workflow reference looks like, but nothing critical is missing.
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 50%: idempotencyKey is already documented in the schema with retry guidance, while title has no description anywhere. The description restates the idempotency behavior but adds no syntax or constraint detail, so the 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?
States a specific verb+resource and even clarifies the result is an 'empty workflow (canvas)', which separates it from apply_workflow_change. It does not name a sibling alternative, but the scope is 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?
Usage is only implied by the creation verb; there is no explicit when-to-use vs. get_workflow/list_workflows/apply_workflow_change guidance. The retry note gives useful operational context but not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Node modes that can be created, each mode’s models with their options and defaults, the allowed canvas connections, and compose aspect ratios.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, but with no output schema, the description adds substantive value by enumerating the return contents: node modes, model options/defaults, allowed connections, and compose aspect ratios. It does not cover error behavior or specific usage constraints, so it stops short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single, front-loaded sentence fragment that lists the key returned entities without filler. It is efficient, though the absence of a verb or lead-in makes it read more like a schema caption than a complete tool description.
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?
With no parameters, a readOnly annotation, and no output schema, the description carries the main burden of explaining what is returned—and it does so by listing the four main capability areas. It is adequate for a low-complexity read tool, though it could add context about when this capability data matters in the workflow lifecycle.
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 tool takes zero parameters, so there is nothing for semantics to clarify. Per the calibration rule, a zero-parameter tool has a baseline of 4, and the description appropriately adds no unnecessary parameter discussion.
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 names the specific content the tool returns—node modes, their models with options/defaults, allowed canvas connections, and compose aspect ratios—which makes the purpose concrete. It does not, however, distinguish this capabilities-discovery tool from workflow-related siblings like create_workflow or run_node, leaving the agent to infer that this is a read-only metadata tool.
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?
There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The description is purely a content list; an agent gets no signal on when this tool should be called versus get_workflow or the other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status and outputs of a generation task. While it is running, wait retryAfterMs before asking again.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds useful behavioral context: it returns status and outputs, and specifies a polling delay (retryAfterMs) while running. It does not cover error handling or full response shape.
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 short sentences with zero waste. The purpose is front-loaded, followed by a compact operational rule. Every sentence earns its place.
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 simple read-only task-status getter, the description covers purpose and polling behavior, but omits parameter guidance and output details (no output schema), leaving gaps for correct invocation.
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 0% and the single parameter taskId is not explained at all. The description implies a task identifier but gives no format, source, or usage details to compensate.
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 phrase 'Status and outputs of a generation task' clearly states what the tool returns, but uses a noun phrase rather than an explicit verb and does not differentiate from sibling tools like get_workflow or run_node.
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?
It gives polling guidance ('While it is running, wait retryAfterMs before asking again'), but offers no guidance on when to choose this tool over alternatives such as get_workflow or list_workflows, leaving selection context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The whole canvas: nodes with their config, files, latest task status and latest successful output; edges; and the revision to pass to apply_workflow_change.
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering the safety profile, the description adds real behavioral value: it discloses the full return surface (nodes, files, task status, latest successful output, edges) and, importantly, the revision field that governs optimistic concurrency for apply_workflow_change. That concurrency signal is context the annotations do not provide.
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?
A single dense sentence front-loads the payload enumeration before the concurrency hint. The semicolon-separated list is slightly heavy but every clause earns its place and nothing is padded.
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?
There is no output schema, so the description correctly carries the burden of describing returns in detail, and it does so well. The only material gap is workflowId's origin/format, and a note on how stale the returned revision may be.
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?
Only one parameter (workflowId) exists, and the schema gives it length constraints but no description (0% coverage); the tool description never explains where the ID comes from or its format. The single obvious parameter keeps this at baseline adequacy rather than a failure.
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 enumerates exactly what the tool returns (nodes with config/files/task status/output, edges, revision), which makes the verb+resource unambiguous even though 'get workflow' is never restated. It implicitly separates itself from list_workflows by returning the 'whole canvas' rather than a summary, but does not name that sibling explicitly.
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?
Usage is only implied: mentioning 'the revision to pass to apply_workflow_change' hints at a read-then-modify flow, but there is no explicit 'use this before calling apply_workflow_change' or guidance versus get_task/list_workflows. An agent can infer context but is not told when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The user’s workflows, most recently updated first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | nextCursor from the previous page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully adds the sort order (most recently updated first), which implies the cursor semantics, but it says nothing about pagination behavior, page size limits, or what an empty result means.
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?
One short sentence with no waste and the key scoping and ordering facts front-loaded. It is efficient, though bordering on under-specified for a paginated list tool.
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?
With no output schema, a nested cursor object, and an undocumented limit parameter, the description leaves pagination mechanics and return shape entirely to inference. For a paginated listing tool this is a meaningful gap.
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 only 50% – limit has no description and only constraint keywords, and cursor carries a brief schema note. The description adds no parameter meaning at all, not even that the updatedAt/id cursor pairs with the stated sort order.
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 names the resource (workflows), its scope (the user's), and the ordering (most recently updated first), which lets an agent recognize it as a listing tool. It does not explicitly contrast itself with the singular sibling get_workflow, so it falls short of the top band.
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?
There is no guidance on when to use this versus get_workflow, create_workflow, or any other sibling; the agent must infer it from the name alone. Listing is the obvious reading, but no alternative or condition is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a one-hour URL to PUT a local image, video, audio or text file to. Send exactly the returned headers, then call complete_upload with the fileKey.
| Name | Required | Description | Default |
|---|---|---|---|
| size | Yes | ||
| filename | Yes | ||
| mimeType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is not read-only/idempotent/destructive, which is thin; the description adds real behavior — the URL expires in one hour, the returned headers must be sent verbatim, and a fileKey is produced for complete_upload. It does not mention auth requirements or what happens to the URL if unused, so it stops short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences; the primary action (get a URL) comes first and the follow-up step second. Every clause carries information and none is redundant.
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?
With no output schema, the description partially covers the return value (URL, headers, fileKey) but does not explain response structure or error modes. Combined with zero parameter documentation and a required size limit, an agent still has gaps before calling it.
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 0% and the description says nothing about filename, mimeType, or size — notably the large positive-integer size ceiling and string length limits are never surfaced. The 'image, video, audio or text file' phrasing loosely hints at accepted mimeTypes but adds no real constraint detail.
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?
States a specific verb (Get) and resource (a one-hour URL to PUT a file to), with accepted file types named. It is clearly the initiation step of a two-phase upload, distinguishable from complete_upload and the workflow 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 routes the agent forward: 'then call complete_upload with the fileKey' and mandates sending the returned headers exactly. It doesn't state conditions where this tool should not be used or how it relates to other siblings, but the sequencing guidance is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spend credits to generate one generation node from its saved config and the latest successful outputs of its upstream nodes. Requires the generate permission.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ||
| workflowId | Yes | ||
| idempotencyKey | Yes | Client-chosen key identifying this request. Retry with the same key; a new request needs a new key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely new behavior: the operation consumes credits and requires the generate permission. It stops short of saying what the destructive aspect actually destroys (e.g., prior node output) or how failures are surfaced.
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 tight sentences with no filler; the core action and its input sourcing come first, followed by the permission requirement. Every clause carries 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?
For a three-parameter mutation with no output schema, the description covers cost, permission, and input semantics adequately, and annotations carry the safety hints. Minor gaps remain around failure behavior and which node state is overwritten.
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 only 33% – only idempotencyKey is documented. The description never explains what workflowId or nodeId select, nor that nodeId must reference a node with saved config and resolvable upstream outputs, so it fails to compensate for the coverage gap.
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?
States a specific verb and resource ('generate one generation node') plus the precise inputs it draws from ('its saved config and the latest successful outputs of its upstream nodes'). This is unambiguous and clearly distinct from the workflow-level siblings like create_workflow or apply_workflow_change.
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?
It states a prerequisite ('Requires the generate permission') and an implicit cost gate ('Spend credits'), which is useful context. However, it never says when to prefer this over alternatives such as apply_workflow_change or a whole-workflow run, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
apply_workflow_changecomplete_uploadcreate_workflowget_capabilitiesget_taskget_workflowlist_workflowsprepare_uploadrun_nodeCreate and edit AI videos from chat: plan shots, generate scenes, and export stories and ads.
Edit video by talking to your AI — search footage, cut timelines, apply effects, add captions.
AI video editor: create projects, edit timelines, add captions and effects, and render videos.
AI editor to build, animate & export layered short-form video projects via one tool catalog.
Add one secure layer between your agents and this server.
