R3

List the Blender models on this R3 account

r3_blender_list

Read-onlyIdempotent

List the Blender models this R3 account has uploaded — one per .blend file name, the current version of each — with what it will produce: how many Blender objects land in the scene, how many meshes and materials, its screenshot, and any PENDING update (a re-upload that changes meshes the user's projects use, waiting for r3_blender_update). An upload with unapplied modifiers is applied in Blender by R3 itself; a model says what was applied, per object. community: true lists everyone's public models instead. Add one (or some of its meshes) to a project with r3_blender_import. A .blend gets here two ways: a person uploads it in the R3 app (Models -> Upload .blend), or you save one you built in Blender with r3_blender_upload (a one-time ticket and an upload endpoint: never a tool argument).

Input Schema

Name	Required	Description
`limit`	No	How many models to return (default 25, max 100).
`cursor`	No	Continue a list: the nextCursor of the previous page.
`search`	No	Only models whose name matches, searched across every model (not the page in hand).
`community`	No	true lists the PUBLIC models of every user (the Community tab) instead of this account's own.

Output Schema

Name	Required	Description
`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.
`filter`	Yes
`models`	Yes
`hasMore`	Yes
`nextCursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / search / description

Previous value: -"Only models whose name matches. Prefer this to paging."New value: +"Only models whose name matches, searched across every model (not the page in hand)."

Changed2 schema fields changedOct 19, 2026

addedOutput schema / properties / models / items / properties / yours
```
Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
```

changedOutput schema / properties / models / items / required

Previous value: -[
-  "blenderModelId",
-  "name",
-  "filename",
-  "owner",
-  "status",
-  "currentFileId",
-  "updatedAt",
-  "meshCount",
-  "objectCount",
-  "isPublic",
-  "thumbnailUrl",
-  "previewPending",
-  "pendingUpdate",
-  "errorMessage",
-  "importState",
-  "legacyReason",
-  "appliedFromUpload",
-  "latestUpload"
-]New value: +[
+  "blenderModelId",
+  "name",
+  "filename",
+  "owner",
+  "yours",
+  "status",
+  "currentFileId",
+  "updatedAt",
+  "meshCount",
+  "objectCount",
+  "isPublic",
+  "thumbnailUrl",
+  "previewPending",
+  "pendingUpdate",
+  "errorMessage",
+  "importState",
+  "legacyReason",
+  "appliedFromUpload",
+  "latestUpload"
+]

Changed1 schema field changedOct 18, 2026

changedOutput schema / properties / models / items / properties / importState / anyOf

Previous value: -[
-  {
-    "enum": [
-      "ok",
-      "needs_reparse",
-      "legacy"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "ok",
+      "needs_reparse",
+      "needs_owner_reparse",
+      "legacy"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

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: -[
-  "models",
-  "filter",
-  "hasMore",
-  "nextCursor"
-]New value: +[
+  "models",
+  "filter",
+  "hasMore",
+  "nextCursor",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses what each result carries (object/mesh/material counts, screenshot, pending-update flag), how R3 applies unapplied modifiers per object, the meaning of a PENDING update, and the important constraint that the upload ticket/endpoint is never a tool argument.

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?

The core purpose is front-loaded in the first sentence and every clause is informative, but it is a dense run-on paragraph that partly duplicates the output schema's field list, so it is slightly over-packed rather than maximally tight.

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 read-only list tool with an output schema present, the description covers scope, entry contents, pagination-adjacent behavior, the community toggle, and how models arrive — everything the agent needs to call it correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the schema documents limit, cursor, search, and community. The description restates community's public-model behavior but adds nothing beyond the schema on limit, cursor, or search, so the baseline 3 applies.

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 ('List the Blender models this R3 account has uploaded') with scope and unit of return ('one per .blend file name, the current version of each'). It distinguishes itself from r3_blender_upload, r3_blender_update, and r3_blender_import by naming each and its role.

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?

Gives clear context for use and routes the agent to siblings: models get here via the R3 app or r3_blender_upload, pending updates wait for r3_blender_update, and adding to a project uses r3_blender_import. It lacks an explicit 'use this instead of X when Y' exclusion, so it falls just short of a 5.

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?