HyperCodeMotion MCP

Propose a gallery template

propose_template

Submit a recreated video as an official HyperCodeMotion Studio gallery template, with the moderator code: the source link, its three compositions (cuadrado 1080×1080, vertical 1080×1920, horizontal 1920×1080) and the gallery card. It checks the source, the compositions and the card; if anything fails it returns accepted: false with the errors to fix and keeps it as a draft with a code, to be fixed with patch (estimated text overflows are only warnings). Do not call validate_json first: this runs the same checks. When accepted, the composition in the original's format is rendered with the Studio engine and compared with the original frame by frame; get_proposal_status returns that comparison. To send fixes after a comparison, call it again with the same code (up to 3 comparisons): send only patch (the changes, applied to the stored compositions; card may be left out) instead of the three full compositions, unless you are redesigning. Nothing is published until publish_template. A video that is already a template is not stored twice.

Input Schema

Name	Required	Description
`url`	Yes	Link of the source video's page, the same one given to get_recreation_brief.
`card`	No	Gallery card, in Spanish. Required on a first proposal; a revision keeps the previous one when left out.
`code`	No	Only to send a revision after a comparison: the tracking code of the first proposal.
`patch`	No	Only with code, instead of compositions: the changes to the stored compositions. Each item {op: replace\|add\|remove\|edit, path: JSON pointer such as /layers/3/props/fontSize or /docs/s1, value (replace, add), find and replace (edit: changes one exact piece of a text such as a doc's HTML or CSS; find must appear once), variants: which of cuadrado, vertical, horizontal (default all three)}.
`adminCode`	Yes	The moderator code the user gave with the link. Required: only moderators can make gallery templates. Never repeat it back.
`compositions`	No	The three compositions, as objects or JSON-encoded strings. Required on a first proposal; a revision may send patch instead.

Output Schema

Name	Required	Description	Default
`code`	No
`round`	No
`errors`	Yes
`status`	No
`message`	No
`accepted`	Yes
`template`	No
`duplicate`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 24, 2026

changedInput schema / properties / card / description

Previous value: -"Gallery card, in Spanish."New value: +"Gallery card, in Spanish. Required on a first proposal; a revision keeps the previous one when left out."

changedInput schema / properties / compositions / description

Previous value: -"The three compositions, as objects or JSON-encoded strings."New value: +"The three compositions, as objects or JSON-encoded strings. Required on a first proposal; a revision may send patch instead."

addedInput schema / properties / patch

Added value: +{
+  "description": "Only with code, instead of compositions: the changes to the stored compositions. Each item {op: replace|add|remove|edit, path: JSON pointer such as /layers/3/props/fontSize or /docs/s1, value (replace, add), find and replace (edit: changes one exact piece of a text such as a doc's HTML or CSS; find must appear once), variants: which of cuadrado, vertical, horizontal (default all three)}.",
+  "items": {
+    "properties": {
+      "find": {
+        "type": "string"
+      },
+      "op": {
+        "enum": [
+          "replace",
+          "add",
+          "remove",
+          "edit"
+        ],
+        "type": "string"
+      },
+      "path": {
+        "type": "string"
+      },
+      "replace": {
+        "type": "string"
+      },
+      "value": {},
+      "variants": {
+        "items": {
+          "enum": [
+            "cuadrado",
+            "vertical",
+            "horizontal"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "op",
+      "path"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "url",
-  "adminCode",
-  "compositions",
-  "card"
-]New value: +[
+  "url",
+  "adminCode"
+]

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / adminCode

Added value: +{
+  "description": "The moderator code the user gave with the link. Required: only moderators can make gallery templates. Never repeat it back.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "url",
-  "compositions",
-  "card"
-]New value: +[
+  "url",
+  "adminCode",
+  "compositions",
+  "card"
+]

AddedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only give readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false; the description adds the real behavioral detail: on failure it keeps a draft with code and returns accepted:false with errors, text overflows are warnings only, up to 3 comparisons, and duplicates are not stored twice. That is substantial context beyond the structured fields.

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 action, then the revision workflow, then the publish caveat, so an agent can stop reading early. Some sentences are long with embedded parentheticals ('estimated text overflows are only warnings', the 1080x1080 dimension list) that slow scanning, but nothing is redundant.

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 complex open-world mutation with nested compositions, patch semantics and an output schema, the description covers validation outcome shape, failure recovery, revision limits, dedup and the follow-up tool. Return values are delegated correctly to output_schema and get_proposal_status.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by stating the conditional contract: code+patch replaces the three full compositions, card may be omitted on revision, and patch applies to stored compositions. It does not add format detail for url or adminCode beyond the schema.

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

Purpose5/5

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

States a specific verb and resource ('Submit a recreated video as an official ... gallery template') and names the three artifacts required (source link, three compositions, gallery card). It is immediately distinguishable from publish_template, validate_json and get_proposal_status, all of which are named and given a role.

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

Usage Guidelines5/5

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

Explicitly says 'Do not call validate_json first: this runs the same checks', tells the agent to re-call with the same code for revisions (up to 3 comparisons), to prefer patch over full compositions unless redesigning, and that nothing is published until publish_template. When-to-use and when-not-to-use are both covered.

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

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.