R3

Delete an image, model, audio file or Blender model

r3_asset_delete

Destructive

Delete one of the account's images, models, audio files, Blender models (kind blender: a whole uploaded .blend with every version; its meshes in use stay) or texture sets (kind textureSet: the set and its maps, r3_texture_create made it) — the same reference-guarded delete as the R3 app. With asset:delete:created, only an asset YOU created (this agent key or app connection; today: images made with r3_image_create); with asset:delete:owned, any of the user's assets, and only when the user asked for it: pass owned: true for one you did not create (an app connection is then asked for that right). Two calls, every time: without confirm nothing is deleted, and the answer says what would go and which of the user's projects use it; the same call with confirm: true, when that is what the user wants, deletes it. An asset another user's project uses can never be deleted. A model takes the images only it used with it, an HDR / EXR image its preview image. There is no trash and no undo. Ids come from r3_image_list, r3_audio_list and r3_blender_list.

Input Schema

Name	Required	Description
`id`	Yes	The asset's id, as the list tools report it.
`kind`	Yes	What the id names: blender = a Blender model (its blenderModelId), textureSet = a texture set (its setId).
`owned`	No	true when the asset is one of the user's own, not one you created: it needs asset:delete:owned. Only when the user asked to delete it. Leave out for an asset you created.
`confirm`	No	Leave out on the first call (it only reports). true deletes — after the user has seen the report.
`deleteReleases`	No	With confirm: also move the user's non-live, UNPINNED releases that use it to the 7-day trash (needs release:delete; only when the user asked). Without it those releases are kept: for an image, model or audio file they are marked incomplete; for a Blender model they keep their meshes (the meshes they use stay). Pinned releases are never deleted by an agent.

Output Schema

Name	Required	Description
`id`	Yes
`kind`	Yes
`name`	Yes
`size`	No
`answer`	Yes	This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
`deleted`	Yes
`projects`	Yes
`releases`	No
`meshesKept`	No
`environment`	Yes
`meshesDeleted`	No
`previewProject`	No
`referenceCount`	Yes
`cascadeImageIds`	No
`confirmRequired`	Yes
`releasesDeleted`	No
`releasesMarkedIncomplete`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

addedInput schema / properties / owned

Added value: +{
+  "description": "true when the asset is one of the user's own, not one you created: it needs asset:delete:owned. Only when the user asked to delete it. Leave out for an asset you created.",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 17, 2026

changedInput schema / properties / kind / description

Previous value: -"What the id names: blender = a Blender model (its blenderModelId)."New value: +"What the id names: blender = a Blender model (its blenderModelId), textureSet = a texture set (its setId)."

changedInput schema / properties / kind / enum

Previous value: -[
-  "image",
-  "model",
-  "audio",
-  "blender"
-]New value: +[
+  "image",
+  "model",
+  "audio",
+  "blender",
+  "textureSet"
+]

Changed2 schema fields changedOct 15, 2026

addedOutput schema / properties / answer

Added value: +{
+  "description": "This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "kind",
-  "id",
-  "name",
-  "deleted",
-  "confirmRequired",
-  "referenceCount",
-  "projects",
-  "environment"
-]New value: +[
+  "kind",
+  "id",
+  "name",
+  "deleted",
+  "confirmRequired",
+  "referenceCount",
+  "projects",
+  "environment",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true, but the description goes well beyond them: the two-call report-then-confirm ritual, the fact that without confirm nothing is deleted, 'There is no trash and no undo', cascade effects (a model takes only-unused images with it, an HDR/EXR takes its preview), per-call permission requirements, and cross-project protection. This is exactly the additional context the annotations cannot convey.

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 verb and resource list, and every sentence carries non-redundant information. It is dense, however, with layered parentheticals and em-dash asides that make some clauses hard to parse on first read, slightly diluting scannability.

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?

An output schema exists, so return values need no explanation. For a destructive, permission-gated, cascading tool the description covers the confirm protocol, ownership rules, permission scopes, cascade side effects, irreversibility, and id sources — nothing an agent needs to call it safely is missing.

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 adds real semantics on top: owned:true is for assets 'you did not create' and triggers an app-connection consent, confirm:true only deletes after the user has seen the report, and deleteReleases is scoped to non-live UNPINNED releases. It stops short of restating deleteReleases' full mechanics, which the schema already carries.

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 opening names a specific verb (Delete) and enumerates the exact resources it handles (images, models, audio, Blender models, texture sets), including edge semantics like 'kind blender: a whole uploaded .blend with every version'. It also names the sibling list tools that supply ids, so an agent can distinguish it from the r3_*_list readers without opening a schema.

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 states when to use it (two calls, confirm only when the user wants deletion) and when not to (an asset another user's project uses 'can never be deleted'; owned:true only when the user asked). It names the alternatives for obtaining ids (r3_image_list, r3_audio_list, r3_blender_list) and the permission scopes gating each path.

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

All R3 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.

Resources

Need Help?