R3

List unused images, models and audio

r3_assets_unused

Read-onlyIdempotent

The account's images, models and audio files that nothing uses — no project, no entity template, no other user's project — with each one's size and date, biggest first, and the total. The same report as the R3 app's Settings → Storage, by the same rules the deletes use. A model lists the images only it uses, an HDR / EXR image its preview image: they go with it. A texture set nothing uses is one item (kind textureSet) with its maps under it; a map of a set is never listed on its own. Blender (.blend) files are not part of it: they are the user's to keep or delete, listed by r3_blender_list. Pass kind to see one kind, limit for more rows (the totals always cover everything). It only reads; r3_asset_delete deletes an item by its kind and id (a plan, then a confirm), for what the user asked to remove. The scan can take several seconds.

Input Schema

Name	Required	Description	Default
`kind`	No	Only this kind: image, model, audio or textureSet.
`limit`	No	How many items to list (default 50, at most 200).

Output Schema

Name	Required	Description
`items`	Yes
`shown`	Yes
`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.
`totals`	Yes
`environment`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 17, 2026

changedInput schema / properties / kind / description

Previous value: -"Only this kind: image, model or audio."New value: +"Only this kind: image, model, audio or textureSet."

changedInput schema / properties / kind / enum

Previous value: -[
-  "image",
-  "model",
-  "audio"
-]New value: +[
+  "image",
+  "model",
+  "audio",
+  "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: -[
-  "items",
-  "shown",
-  "totals",
-  "environment"
-]New value: +[
+  "items",
+  "shown",
+  "totals",
+  "environment",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent/open-world safety. The description adds real behavioral context the annotations cannot: the scan 'can take several seconds' (latency), totals always cover everything regardless of limit, and grouping rules (a model carries the images only it uses, a textureSet is one item containing its maps). No permissions/auth notes, so not a full 5.

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?

Inclusion rule is front-loaded, then grouping, then exclusions, then params and sibling routing. Dense and information-rich, though a few clauses (the texture-set/map digression) could be tightened without losing meaning.

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?

Output schema exists, so return values need no prose. Combined with annotations and a fully described schema, the description covers everything an agent needs: inclusion/exclusion rules, grouping semantics, latency, param effects and the correct sibling for deletion.

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% (baseline 3), and the description adds a non-obvious semantic: `limit` widens rows but the totals always cover everything, so the agent knows limiting does not truncate the aggregate. `kind`'s role is restated but not enriched beyond the enum.

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 concrete verb+resource with scope: 'the account's images, models and audio files that nothing uses'. It defines 'unused' precisely (no project, no entity template, no other user's project) and explicitly distinguishes itself from siblings r3_asset_delete, r3_blender_list, r3_image_list and r3_audio_list.

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?

Explicit routing: use this to see what is unused, use r3_asset_delete to remove an item (with plan-then-confirm), use r3_blender_list for .blend files that are excluded here. Both the when and the when-not are stated.

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?