Morpha

Delete version

delete_version

Destructive

Permanently delete one saved version (bookmark or auto-snapshot). Accepts the version's UUID id or the v<N> shorthand. The bookmark v sequence keeps gaps — numbers never re-shuffle — so any external snippet referencing the deleted v<N> will fail to resolve afterwards. Idempotent: deleting a non-existent version is a no-op.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`projectId`	Yes	Project whose version to delete.
`versionId`	Yes	Version to delete. UUID `id` or `v<N>` shorthand.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the call succeeded.
`data`	No	The payload, shaped by the tool.
`note`	No	What to do next when not ready.
`error`	No	Why it failed.
`status`	No	For cache-backed readers: whether the answer was ready.
`editorUrl`	No	Opens this project in the editor.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 17, 2026

removedInput schema / properties / anonymousToken

Removed value: -{
-  "description": "The token create_anonymous_account returned. This connection has no Morpha key, so every call carries it.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "projectId",
-  "versionId",
-  "anonymousToken"
-]New value: +[
+  "projectId",
+  "versionId"
+]

Changed1 schema field changedSep 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "The result envelope every Morpha tool returns.",
+  "properties": {
+    "data": {
+      "description": "The payload, shaped by the tool.",
+      "type": [
+        "object",
+        "array",
+        "string",
+        "number",
+        "boolean",
+        "null"
+      ]
+    },
+    "editorUrl": {
+      "description": "Opens this project in the editor.",
+      "type": "string"
+    },
+    "error": {
+      "description": "Why it failed.",
+      "type": "string"
+    },
+    "note": {
+      "description": "What to do next when not ready.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the call succeeded.",
+      "type": "boolean"
+    },
+    "status": {
+      "description": "For cache-backed readers: whether the answer was ready.",
+      "enum": [
+        "ready",
+        "not-ready"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedSep 11, 2026

addedInput schema / properties / anonymousToken

Added value: +{
+  "description": "The token create_anonymous_account returned. This connection has no Morpha key, so every call carries it.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "projectId",
-  "versionId"
-]New value: +[
+  "projectId",
+  "versionId",
+  "anonymousToken"
+]

First observedSep 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds substantial behavioral context beyond that: it is permanent, accepts both UUID and v<N>, the v<N> sequence keeps gaps causing external snippets to fail, and it is idempotent with a no-op for non-existent versions. This is exactly the kind of side-effect and post-condition disclosure that agents need.

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

Conciseness5/5

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

The description is three sentences with minimal waste. It front-loads the primary purpose, then provides the two most important operational details (accepted identifiers and side effects) in compact, well-structured sentences. Every sentence earns its place.

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 delete operation with two parameters, destructive annotations, and an output schema present, the description is complete. It covers what is deleted, how to identify it, the irreversible side effect, the v<N> gap behavior, and idempotency. There is no missing information an agent would need to call this tool correctly.

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. The description adds value beyond the schema by explaining the consequences of using v<N> shorthand (gaps remain, external references break) and by clarifying idempotent behavior for non-existent versions. This is meaningful semantic enrichment even though the schema already documents both parameters.

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?

The description clearly states the tool's action: 'Permanently delete one saved version (bookmark or auto-snapshot).' It uses a specific verb and resource, and distinguishes this from sibling tools like delete_page, delete_project, and restore_version by naming the target as a saved version. The mention of UUID and v<N> shorthand further clarifies the exact scope.

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 gives clear context for use: it is for permanently deleting a saved version, which implies the appropriate situation. However, it does not explicitly name alternatives such as restore_version or list_versions for comparison, nor does it state when NOT to use this tool. It stops short of the explicit 'use X instead' guidance seen in top-tier examples.

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

All Morpha 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?