Blender Bridge

Panel: list or preview project files

view_files

Read-onlyIdempotent

App-only adapter for the project-file list and image-preview area in the Blender Bridge panel. action=list returns existing workspace file metadata in view.files; it needs no path. action=preview requires a workspace-relative file path from that list and returns a bounded preview in view.preview. Absolute disk paths are omitted from the list payload. Does not save, render or prepare a download link. Missing paths or failed file reads return project_file_action_failed. Models should use list_project_files to discover results and get_project_file to retrieve a requested file.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "view_files"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No	Workspace-relative path from the file list; required for preview, unnecessary for list.
`action`	Yes	list reads workspace file records; preview reads an image preview for the given path.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / action / description

Added value: +"list reads workspace file records; preview reads an image preview for the given path."

addedInput schema / properties / path / description

Added value: +"Workspace-relative path from the file list; required for preview, unnecessary for list."

First observedOct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds substantial context: output locations (view.files/view.preview), omission of absolute disk paths, excluded side effects (no save/render/download link), and the project_file_action_failed error case. No contradiction with annotations.

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 front-loaded with purpose, then organized by action, exclusions, error behavior, and alternatives. Every sentence adds relevant information, with no obvious 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?

For a two-action, two-parameter panel adapter with no output schema, the description supplies enough detail about return locations, path requirements, error behavior, and alternative tools. An agent has what it needs to invoke this 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 description coverage is 100%, and both action and path are already documented in the schema. The description mostly restates the action-specific requirements and adds only the detail that absolute disk paths are omitted from the list payload, so it does not meaningfully expand parameter semantics beyond the schema.

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 names the specific resource (project files) and the two operations (list metadata and preview images), and it explicitly distinguishes this panel adapter from sibling tools list_project_files and get_project_file. An agent can identify what the tool does without opening the 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?

It states action-specific conditions—list needs no path, preview requires a workspace-relative path from the list—and explicitly routes discovery and retrieval to list_project_files and get_project_file. It also says what the tool does not do, which helps exclude incorrect use.

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

All Blender Bridge 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?