HyperCodeMotion MCP

Create HyperCodeMotion project file

create_hcmotion

Validate a finished HyperCodeMotion composition and package it as a .hcmotion project file, the format HyperCodeMotion Studio opens. If the composition has problems, returns created: false with the errors to fix and stores nothing. On success, stores the file temporarily and returns an open link (opens the project in HyperCodeMotion Studio) and a download link; both expire 24 hours after creation. Pass the user's images, videos and audio in media (public https links, or files sent with start_media_upload) and they travel inside the file, so the project opens complete. It does not render video or generate media.

Input Schema

Name	Required	Description
`json`	Yes	The full composition (version, name, width, height, fps, duration, background, layers…), as an object or JSON-encoded string.
`name`	No	Optional project name.
`media`	No	The user's images, videos, audio or fonts to pack inside the file (binary, max 200 MB in total). Each item: {id, url} with a public https link the server downloads, or {id, upload} with the upload code from start_media_upload once the file was received. Layers use it as props.asset = id (image, video, audio) or <img src="asset:id"> in an HTML scene.

Output Schema

Name	Required	Description	Default
`open`	No
`bytes`	No
`media`	No
`errors`	Yes
`created`	Yes
`download`	No
`warnings`	Yes
`expiresAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026

addedInput schema / properties / media

Added value: +{
+  "description": "The user's images, videos, audio or fonts to pack inside the file (binary, max 200 MB in total). Each item: {id, url} with a public https link the server downloads, or {id, upload} with the upload code from start_media_upload once the file was received. Layers use it as props.asset = id (image, video, audio) or <img src=\"asset:id\"> in an HTML scene.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "string"
+      },
+      "upload": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id"
+    ],
+    "type": "object"
+  },
+  "maxItems": 40,
+  "type": "array"
+}

addedOutput schema / properties / media

Added value: +{
+  "items": {
+    "properties": {
+      "bytes": {
+        "type": "number"
+      },
+      "id": {
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

AddedOct 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only supply the generic mutation/safety flags (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries the real disclosure and does it well: failure returns created:false with errors and stores nothing, success stores the file temporarily, and both open/download links expire after 24 hours. It also discloses that media binaries travel inside the packaged file and are capped, plus the 24-hour lifetime constraint an agent must communicate to the user.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the failure path, then output/lifetime, then media — a logical order an agent can parse quickly. The media sentence partially duplicates the schema's own media description, which is the only real waste across three otherwise dense sentences.

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

Completeness5/5

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

For a three-parameter packaging tool with an output schema, the agent has everything needed to call it correctly: input expectations, success and failure shapes, link lifetime, media capacity constraints, and the explicit non-goal of rendering. The output schema covers return structure, so the description does not need to enumerate fields further.

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 json, name and the media item shape, and the description largely restates it ('public https links, or files sent with start_media_upload'). It does add the integration point with the start_media_upload sibling and the layer reference convention, which is genuinely useful cross-tool context. Baseline 3 is appropriate since the schema does the heavy lifting.

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+resource pair: 'Validate a finished HyperCodeMotion composition and package it as a .hcmotion project file, the format HyperCodeMotion Studio opens.' This clearly separates it from validate_json (validation only) and start_media_upload (media intake) among the siblings, and the trailing 'It does not render video or generate media' rules out the most likely confusion.

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?

The description makes clear this is the terminal step for a finished composition and explicitly excludes rendering/generation, which routes the agent away from a wrong expectation. It also implies the companion workflow by naming start_media_upload for files not yet hosted. It stops short of naming validate_json as a cheaper pre-check, so no explicit alternative is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HyperCodeMotion MCP tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.