Blender Bridge

Panel: choose computer

view_select_computer

DestructiveIdempotent

App-only adapter for the connection panel's computer selector. device_id identifies an own or approved shared computer listed for this account. Changes the target for this conversation, not its transport or access permissions, and returns refreshed connection state. A selected offline computer is not silently replaced with another target. Does not launch Blender. Models should use select_computer on the hosted connector or set_connection in a native Desktop plugin.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "view_select_computer"
  }
}

Input Schema

Name	Required	Description	Default
`device_id`	No	Account computer identifier selected in the panel; omit to clear the explicit selection.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / device_id / description

Added value: +"Account computer identifier selected in the panel; omit to clear the explicit selection."

First observedOct 23, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds real context beyond them by scoping the effect (changes this conversation's target, not transport or permissions), stating the return ('refreshed connection state'), and noting that an offline selection is not silently swapped and that Blender is not launched. It never explains why the operation is flagged destructive, so it falls short of a 5.

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?

Six short clauses, each carrying distinct information: scope, parameter meaning, effect, offline behavior, non-behavior, and routing. Errors and side effects are front-loaded rather than buried.

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?

With a single optional parameter, no output schema, and destructive annotations, the description covers what an agent needs: what it mutates, what it does not mutate, what comes back, and where to go instead.

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 a constraint the schema lacks: device_id must identify an own or approved shared computer listed for this account. The omit-to-clear behavior is already in the schema and is only echoed.

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+resource ('adapter for the connection panel's computer selector') and immediately bounds scope to this conversation's target. It also names the sibling tools that cover the same job elsewhere (select_computer, set_connection), so an agent can separate it from lookalikes without opening any 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 routes the agent: use select_computer on the hosted connector, or set_connection in a native Desktop plugin, implying this tool is for the in-app panel only. That is both a when-to-use and a when-not-to-use statement, with named alternatives.

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?