Clypmint

Inspect a video project

get_project_context

Read-onlyIdempotent

Read an owned video’s version, scenes, captions and editable canvas element IDs/capabilities. Optional output_id selects a clip/format; element_offset pages through the canvas inventory. Use the returned version/output, IDs and capabilities with the named direct-edit tools, such as set_element_content or set_element_layout, without a second Clypmint model round. Canvas image IDs name assets already in this version. Returns project data without a visual card.

Input Schema

Name	Required	Description	Default
`video_id`	Yes
`output_id`	No
`element_offset`	No

Output Schema

Name	Required	Description	Default
`code`	No
`cost`	No
`error`	No
`state`	No
`scenes`	No
`status`	No
`dry_run`	No
`message`	No
`plan_id`	No
`captions`	No
`style_id`	No
`video_id`	No
`available`	No
`import_id`	No
`output_id`	No
`studio_url`	No
`version_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 14, 2026

addedInput schema / properties / element_offset

Added value: +{
+  "maximum": 100000,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / output_id

Added value: +{
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

Changed1 schema field changedOct 13, 2026

changedInput schema / $schema

Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"

Changed1 schema field changedOct 12, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Clypmint get_project_context result. Error results carry error; successful requests expose the identifiers and state available for the next step. Signed media stays in private metadata.",
+  "properties": {
+    "available": {
+      "type": "boolean"
+    },
+    "captions": {
+      "type": [
+        "array",
+        "object",
+        "null"
+      ]
+    },
+    "code": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "cost": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "dry_run": {
+      "type": "boolean"
+    },
+    "error": {
+      "type": "string"
+    },
+    "import_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "message": {
+      "type": "string"
+    },
+    "output_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "plan_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "scenes": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "state": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "status": {
+      "type": [
+        "string",
+        "integer",
+        "null"
+      ]
+    },
+    "studio_url": {
+      "format": "uri",
+      "type": "string"
+    },
+    "style_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "version_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "video_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

AddedOct 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met; the description still adds real context: no visual card is returned, no second model round is needed for edits, and canvas image IDs refer to assets already present in this version. Pagination behavior is mentioned but page granularity and bounds are not.

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?

Five sentences, front-loaded with what is returned, then parameters, then downstream usage, then return-shape caveat. Dense but every sentence carries information; only the phrasing is slightly compressed ('version/output') rather than padded.

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

Completeness4/5

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

With an output schema present, the description does not need to enumerate return fields, and it correctly focuses on scope, parameter meaning, and how to use the result. The remaining gap is paging mechanics (page size, when to stop) for a canvas inventory that could be large.

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 description coverage is 0%, so the description carries the burden and mostly does: output_id is explained as selecting a clip/format, and element_offset as paging through the canvas inventory. video_id's ownership constraint is stated ('an owned video'), though the page size or default for element_offset is not given.

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

Purpose4/5

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

The description names a specific verb and resource with concrete scope: version, scenes, captions, and editable canvas element IDs/capabilities for an owned video. It implicitly distinguishes itself from mutation siblings by pointing at set_element_content and set_element_layout as consumers of its output, though it never explicitly contrasts with read siblings like list_versions or check_video.

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

Usage Guidelines3/5

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

It gives a clear downstream-use pattern (feed the returned version/output, IDs, and capabilities directly into the direct-edit tools without a second model round), which implies when to reach for this tool. However, there are no explicit when-not-to-use conditions or a named read alternative (e.g., list_versions for version history, check_video for validation), leaving the agent to infer routing.

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

All Clypmint tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?