Blender Bridge

Export GLB model

export_glb

Export existing mesh content as a GLB result for a web or compatible 3D viewer, converting scene units to meters. The project/filename options choose a new output and operation_name is its history title. Existing output destinations are refused rather than overwritten. Returns export/output status; poll a returned running request_id instead of starting the export again. Use export_model for target-specific FBX, USDZ or STL workflows, save_blend_file for a complete editable Blender scene, or get_project_file to retrieve a result already created.

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": {
      "operation_name": "<operation_name>"
    },
    "name": "export_glb"
  }
}

Input Schema

Name	Required	Description
`filename`	No	Output filename for this result; choose a name appropriate to the requested format.
`project_name`	No	Project name used to organize this output in the receiving Desktop workspace.
`project_path`	No	Absolute project folder only when the user explicitly supplied this external destination. Otherwise use Desktop’s configured workspace.
`operation_name`	Yes	Short, concrete history title in the user's language describing the requested operation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 23, 2026

addedInput schema / properties / filename / description

Added value: +"Output filename for this result; choose a name appropriate to the requested format."

addedInput schema / properties / operation_name / description

Added value: +"Short, concrete history title in the user's language describing the requested operation."

addedInput schema / properties / project_name / description

Added value: +"Project name used to organize this output in the receiving Desktop workspace."

First observedOct 23, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Adds real behavioral context beyond annotations: unit conversion to meters, refusal to overwrite existing destinations (consistent with destructiveHint=false), and returning export/output status with a pollable request_id. These are non-obvious traits the agent could not infer from structured fields, though the overwrite-refusal is stated without detailing the error surfaced to the caller.

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?

Front-loads purpose and format, then parameters, then behavior, then alternatives — a logical call-decision order. Every sentence carries information: units, overwrite policy, polling semantics, sibling routing; no filler or restatement of the title.

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?

No output schema exists, so the description carries the return burden and does so ('Returns export/output status; poll a returned running request_id'). For a 4-param, non-idempotent, open-world export tool, nothing an agent needs to call it correctly is missing.

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 relational meaning the schema lacks: project_name/filename together select a *new* output, and operation_name is only the history title rather than a file identifier. That distinction is exactly the kind of confusion an agent would otherwise hit.

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 ('Export existing mesh content as a GLB result') plus the format rationale (web/compatible 3D viewer, scene units to meters). It explicitly distinguishes itself from export_model, save_blend_file, and get_project_file, so an agent can route without opening schemas.

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?

Names three alternatives and the exact condition that selects each: export_model for target-specific FBX/USDZ/STL, save_blend_file for editable scenes, get_project_file for already-created results. It also gives operational guidance to poll a returned request_id instead of re-invoking.

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?