R3

List the images on this R3 account

r3_image_list

Read-onlyIdempotent

List the images this R3 account owns, with the URL to use for each one. That URL is exactly what R3ComponentTexture.url takes, so this is how you find the account's own artwork — a wood grain, a logo, a skybox — and then point a texture at it with r3_component_set.

Search by name rather than paging: search: "wood" is matched against every image on the account by the server, not against the page you happen to be holding.

Each row says whether it is a "texture" (an ordinary image for a material slot) or an "environment" map (.hdr / .exr). Those two are not interchangeable: an environment map belongs on Scene.environment, Scene.backgroundTexture or MaterialStandard.envMap, and renders as garbage in an ordinary map slot.

You cannot upload an existing image file from here — a tool argument is JSON, this server cannot read your disk, and a real texture is megabytes. A person uploads those in the R3 app. r3_image_create is the one exception: it takes a small image you generated yourself, such as a checkerboard or a gradient.

Input Schema

Name	Required	Description
`limit`	No	How many to return (default 25, max 100).
`cursor`	No	Continue a previous listing: pass the nextCursor it returned, unchanged. Omit for the first page.
`search`	No	Match this text against the file names, on the server. Omit for everything.

Output Schema

Name	Required	Description
`limit`	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.
`images`	Yes
`search`	Yes
`hasMore`	Yes
`nextCursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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: -[
-  "images",
-  "limit",
-  "search",
-  "hasMore",
-  "nextCursor"
-]New value: +[
+  "images",
+  "limit",
+  "search",
+  "hasMore",
+  "nextCursor",
+  "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?

Goes well beyond the readOnly/idempotent annotations: it discloses that each row is typed "texture" vs "environment", that these are not interchangeable and where each belongs, and that the returned URL is directly consumable by R3ComponentTexture.url. That is real operational context an agent cannot get from the annotations.

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 purpose, and every paragraph carries distinct, non-redundant information (search behavior, asset typing, upload boundary). It is longer than strictly necessary and could be tightened, but no sentence is filler.

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-field documentation is not needed. What an agent needs beyond that — what the URL is for, how the rows differ in kind, the search-vs-paging choice, and the boundary with r3_image_create — is all present.

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 limit/cursor semantics are already covered and the baseline is 3. The description earns above baseline by clarifying that search is evaluated server-side against every image on the account rather than the currently held page — a behavioral nuance the schema's "on the server" phrasing does not fully explain.

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 images this R3 account owns") plus the return payload's key field ("the URL to use for each one"). It also implicitly separates itself from siblings that create or delete assets, and explicitly names r3_image_create as the only upload path.

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?

Gives explicit when-to-use guidance ("Search by name rather than paging"), explains why (server-side match across the whole account, not the current page), and names the alternative tool for the adjacent job (r3_image_create). It also states the one thing you cannot do here (upload an existing file) and why.

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?