Skip to main content
Glama

ellmos Blender Use MCP

🇩🇪 Deutsche Version

Part of the ellmos-ai family and the open-bricks open-source initiative.

npm version npm downloads CI Tests License: MIT Attribution: NOTICE Node.js Platform Privacy Security Security SLA Code Style LLM-Ready Glama Ecosystem Umbrella Last-checked


Quick Navigation

Language / Sprache: 🇬🇧 English | 🇩🇪 Deutsch

1. Key Capabilities • 2. Target Personas & Discoverability • 3. Comparative Matrix • 4. Architecture & Topology • 5. Verification Lifecycle • 6. Tool Suite • 7. FBX Verification Deep Dive • 8. Visual Verification Deep Dive • 9. General Primitives • 10. CI/CD Integration • 11. Governance Invariants • 12. Security Policy • 13. Installation • 14. Configuration • 15. Level 1 SBOM • 16. Ecosystem • 17. LLM Context • 18. License & Statutory Notice


1. Key Capabilities

An asset-QA tool for game and 3D asset pipelines: verify that an exported FBX actually reimports cleanly in headless Blender — mesh count, material count, and required naming prefixes checked automatically, with a deterministic JSON result instead of a manual eyeball pass. blender_verify_fbx_reimport is the core structural tool and blender_verify_visual its visual counterpart — the first counts meshes and checks name prefixes, the second renders four views and measures geometry that counting cannot see. blender_locate and blender_run_script are the general-purpose primitives both are built on.

No add-on. No TCP port. No background daemon. This server does not install anything into Blender, does not open a socket for a running Blender instance to connect to, and does not keep Blender resident. Each call spawns blender --background --python <script.py>, waits for a bounded, timeout-guarded exit, and returns the result — headless and stateless by design. It does not download assets and does not collect telemetry.

How this differs from other Blender MCP servers. Most Blender MCP projects (e.g. ahujasid/blender-mcp, the official Blender Labs MCP server) drive a live, running Blender GUI over a TCP/add-on bridge for interactive scene editing — a different use case with a different trust model (an open socket, an installed add-on, a persistent process). This server instead targets CI-style, one-shot asset verification: run it in a pipeline step, get a pass/fail JSON, move on. If you need live GUI control, use a reviewed Blender MCP add-on separately (see Safety below).

NOTE

AI / LLM Integration & Machine-Readable Context: AI assistants (Claude, Codex, Gemini) can read llms.txt for machine-readable context, search phrases, and tool documentation. Regression test suites guard privacy hygiene and runtime memory safety.

TIP

CI & Asset Pipeline Automation: Use blender_verify_fbx_reimport as an automated gate before committing 3D assets to source control. It flags missing prefixes (e.g., SM_, M_), unexpected mesh counts, or broken material assignments without human intervention.


Related MCP server: blender-MCP

2. Target Personas & High-Intent Discoverability

[PERSONA-01] Indie & AAA Game Technical Artists & 3D Pipeline TDs

  • Profile: Technical Artists managing FBX/GLTF asset pipelines for Unreal Engine, Unity, Godot, and custom C++ game engines.

  • Pain Point: Exported 3D assets frequently have unapplied rotation (lying on their side in-engine), broken pivot offsets, missing SM_/M_ prefixes, or unassigned materials that slip past manual review.

  • High-Intent Queries: blender fbx reimport verification mcp, blender headless asset qa gate, automated fbx naming convention check, detect unapplied rotation fbx blender.

  • How We Solve It: One-shot structural reimport verification and 4-view visual geometry checks without having to open the Blender GUI.

[PERSONA-02] CI/CD Automation & Build Infrastructure Engineers

  • Profile: DevOps and Build Engineers responsible for automated asset validation gates in GitHub Actions, GitLab CI, or Jenkins.

  • Pain Point: Traditional Blender automation tools require installing graphical add-ons or running interactive background sockets, which fail in headless containerized runners.

  • High-Intent Queries: headless blender asset qa mcp server, github actions blender fbx qa gate, blender background script ci cd verification, blender mcp no add-on no tcp port.

  • How We Solve It: Stateless blender --background execution with strict 15-minute runaway timeouts, bounded 8 KB memory tails, zero add-ons, and deterministic JSON exit codes.

[PERSONA-03] Autonomous AI Agent Engineers (Claude, Codex, Gemini)

  • Profile: Developers deploying autonomous AI coding agents for procedural 3D generation, asset processing, and game prototyping.

  • Pain Point: AI agents need to inspect and verify 3D assets without socket leaks, zombie processes, or uncontrolled memory consumption.

  • High-Intent Queries: mcp server fbx mesh material verification, ai agent blender 3d asset inspection, blender four-view rendering mcp, llm tool headless blender.

  • How We Solve It: Native Model Context Protocol (MCP) server with comprehensive llms.txt documentation, robust taskkill /T /F process tree termination, and fail-closed temporary file cleanup.

[PERSONA-04] Enterprise Game Studio Compliance & Security Officers

  • Profile: Security Officers and Compliance Managers safeguarding proprietary game IP and development workstations.

  • Pain Point: Third-party DCC tools frequently open local network ports, dial remote telemetry servers, or require administrator privileges.

  • High-Intent Queries: offline blender mcp zero egress, air gapped 3d asset verification, unprivileged blender asset qa, zero copyleft mcp tool.

  • How We Solve It: Strict RunAsInvoker non-elevation certification, 100% offline zero-egress guarantee, zero runtime telemetry, and Level 1 SBOM with 0% copyleft licenses.


3. 10-Dimension Comparative Matrix vs. Alternatives

Invariant / Dimension

[1] ellmos-blender-use-mcp

[2] Interactive Blender MCP (TCP Add-on)

[3] Ad-Hoc Python Scripts

[4] Heavy DCC Suites (Maya / 3ds Max QA)

[5] Cloud SaaS 3D Checkers (Sketchfab)

INV-LOCAL-01: Network & Air-Gap

100% Offline / Zero-Egress (0 network calls)

Open TCP localhost listener required

Local, but unbounded network access

Local, but heavy license server polling

Remote SaaS upload required (Egress risk)

INV-HEADLESS-02: Add-on Burden

Zero Add-ons (works out of the box)

Requires Blender add-on installation

No add-on required

Proprietary plugin installations

Web browser or heavy client upload

INV-SEC-03: Privilege Model

Unprivileged RunAsInvoker (User mode)

User mode, but open socket attack surface

Unrestricted script execution

Administrator/Service installation

SaaS cloud security boundary

INV-BOUND-04: Memory Bounding

Hard Tail Buffer (8 KB - 50 KB max)

Unbounded GUI session memory

Unbounded console output memory

Unbounded workstation memory footprint

Cloud processing quotas

INV-INTEG-05: Structured JSON QA

Deterministic Machine-Readable JSON

Text prompt / chat responses

Unstructured stdout prints

XML / propriety log reports

Web dashboard visualization

INV-VISUAL-06: 4-View Geometry

Standardized 4-View Render Pipeline

Manual GUI eyeball rotation

Requires custom camera scripts

Manual viewport navigation

Single WebGL model viewer

INV-CLEAN-07: Ephemeral Cleanup

Fail-Closed Automated Temp Purge

Persistent scene state in memory

Leftover .py/.blend scratch files

Heavy project temp directories

Remote cloud storage retention

INV-CROSS-08: Cross-Platform

Windows, Linux, macOS Parity

Dependent on GUI desktop support

OS-dependent path handling

OS-constrained (primarily Windows)

Platform-independent browser

INV-SYNC-09: Lock & Sync Defense

Multi-Host Lock & Sync Hardened

Vulnerable to file locking collisions

No lock awareness

Heavy proprietary file locks

No multi-device git discipline

INV-SLA-10: Security SLA

48h Intake / 5d Triage Commitment

Community best-effort (no SLA)

No formal support

Enterprise support contract required

Generic SaaS ticket queue


4. Architecture & Component Topology

graph TD
    subgraph Client ["AI Assistant & Client Environment"]
        AI["AI Agent (Claude / Codex / Gemini)"]
        Config["MCP Configuration (npx / node)"]
    end

    subgraph Server ["ellmos Blender Use MCP Server"]
        MCP["MCP Protocol Server (src/index.js)"]
        subgraph Tools ["Tool Handlers"]
            T1["blender_verify_fbx_reimport"]
            T2["blender_run_script"]
            T3["blender_locate"]
            T4["blender_verify_visual"]
        end
        Safety["Timeout & Tail Buffer Guard (8k chars)"]
    end

    subgraph Subprocess ["Headless Subprocess (Isolated)"]
        Exe["Blender Executable (blender --background)"]
        Python["Temp Python Verification Script"]
        FBX["Target FBX Asset File"]
        JSONOut["Deterministic JSON Result"]
    end

    AI -->|JSON-RPC Request| MCP
    MCP --> Tools
    T1 -->|Generates script & spawns| Exe
    T2 -->|Executes arbitrary python| Exe
    T3 -->|Locates binary| Exe
    T4 -->|Generates visual verification script & spawns| Exe
    Exe --> Python
    Python --> FBX
    FBX -->|Mesh / Material / Naming QA| JSONOut
    JSONOut --> Safety
    Safety -->|Bounded Response| AI

    style Client fill:#1e1e2e,stroke:#89b4fa,stroke-width:1px
    style Server fill:#181825,stroke:#cba6f7,stroke-width:1px
    style Subprocess fill:#11111b,stroke:#a6e3a1,stroke-width:1px

5. Headless Asset-QA Verification Lifecycle

sequenceDiagram
    autonumber
    actor Client as AI Assistant / CI Pipeline
    participant Server as ellmos Blender Use MCP
    participant Resolver as Blender Resolver
    participant Process as Headless Subprocess
    participant Python as Blender Python Engine
    participant FS as Local Filesystem (FBX)

    Client->>Server: Call blender_verify_fbx_reimport(fbxPath, requiredPrefixes)
    Server->>Resolver: Resolve Blender Executable (blender_locate / BLENDER_EXE / Registry / PATH)
    Resolver-->>Server: Return Validated Executable Path
    Server->>FS: Write Temp Python Verification Script
    Server->>Process: Spawn blender --background --python script (timeout-guarded)
    Process->>Python: Execute Verification Script
    Python->>FS: bpy.ops.import_scene.fbx(filepath=fbxPath)
    FS-->>Python: Parse Mesh Objects & Material Slots
    Python->>Python: Validate Naming Prefixes, Object Counts & Hierarchy
    Python->>FS: Write Output JSON Verification Result
    Process-->>Server: Process Exit (Exit Code 0 / Bounded Tail Buffer)
    Server->>FS: Read Result & Clean Up Temp Verification Script
    Server-->>Client: Deterministic JSON Result (meshCount, materialCount, missingPrefixes, ok)

6. Tool Suite & Verification Matrix

Tool

Purpose

Primary Output

Memory Guard

blender_verify_fbx_reimport

Generate a temporary Blender verification script, import an FBX, and write a JSON result with mesh/material counts and missing required prefixes.

JSON Report

Bounded 8 KB Tail

blender_verify_visual

Render four views of an FBX and check geometry a structural reimport cannot see: unapplied rotation, floating parts, pivot outside the model, transform residuals, stray empties.

4 PNGs + JSON

Bounded 8 KB Tail

blender_run_script

Run blender --background --python <script.py> with optional arguments and bounded stdout tail.

Script Tail Text

8 KB - 50 KB Max

blender_locate

Resolve the Blender executable from an explicit path, BLENDER_EXE, standard Windows install locations, or PATH.

Resolved Path

Zero Subprocess


7. blender_verify_fbx_reimport Deep Dive & Schema

Imports an FBX file into headless Blender and verifies mesh count, empty count, material count, material slot assignments, and required naming prefixes.

Parameters

Parameter

Type

Required

Default

Description

fbxPath

string

Yes

—

Target FBX asset file path to verify.

resultPath

string

No

<fbxDir>/verify_reimport_result.json

Path where structured JSON verification results will be written.

requiredPrefixes

string[]

No

[]

List of naming prefixes required on meshes or empties (e.g. ["SM_", "M_"]).

blenderPath

string

No

auto-detect

Custom path to the Blender executable (blender.exe / blender).

timeoutMs

number

No

120000

Process execution timeout in milliseconds (max: 600000).

Example Invocation

{
  "fbxPath": "assets/models/SM_Watchtower_01.fbx",
  "requiredPrefixes": ["SM_", "M_"]
}

Deterministic Output Schema

{
  "ok": true,
  "blender": "C:\\Program Files\\Blender Foundation\\Blender 4.2\\blender.exe",
  "fbxPath": "C:\\projects\\game\\assets\\models\\SM_Watchtower_01.fbx",
  "resultPath": "C:\\projects\\game\\assets\\models\\verify_reimport_result.json",
  "exitCode": 0,
  "timedOut": false,
  "durationMs": 1820,
  "outputTruncated": false,
  "verification": {
    "ok": true,
    "fbx": "C:\\projects\\game\\assets\\models\\SM_Watchtower_01.fbx",
    "mesh_count": 3,
    "empty_count": 0,
    "material_count": 2,
    "materials": [
      "M_Stone_Brick",
      "M_Wood_Trim"
    ],
    "missing_prefixes": [],
    "script_free": true
  }
}

8. Visual Verification Deep Dive & 4-View Geometry

Renders four views of an FBX and checks geometry that a structural reimport cannot see.

blender_verify_fbx_reimport counts meshes and checks name prefixes — it cannot tell you that a mesh is lying on its side, that a part floats away from the assembly, or that the pivot sits outside the model. This tool does, and it produces the renders to look at.

{ "fbxPath": "kit.fbx", "outDir": "verify_visual", "expectHeight": "2.5,3.5" }

Four-View Orthogonal Projection & Failure Detection

+---------------------------------------+---------------------------------------+
|              TOP VIEW                 |           PERSPECTIVE VIEW            |
|              (XY Plane)               |              (Isometric)              |
|                                       |                                       |
|   Detects: X/Y planar alignment,      |   Detects: Overall silhouette,        |
|   bounding box symmetry, footprint    |   complex assembly integration        |
+---------------------------------------+---------------------------------------+
|             FRONT VIEW                |               SIDE VIEW               |
|              (XZ Plane)               |              (YZ Plane)               |
|                                       |                                       |
|   Detects: Model height, Z-grounding, |   Detects: Depth errors, floating vs  |
|   upright orientation (lying down)    |   resting parts, pivot offset         |
+---------------------------------------+---------------------------------------+

Detected failure classes: unapplied rotation, floating parts in multi-part assets, pivot/origin outside the bounding box, transform residuals in the export, stray empties.

Deterministic Output Schema

{
  "ok": true,
  "blender": "C:\\Program Files\\Blender Foundation\\Blender 4.2\\blender.exe",
  "fbxPath": "C:\\projects\\game\\kit.fbx",
  "outDir": "C:\\projects\\game\\verify_visual",
  "exitCode": 0,
  "timedOut": false,
  "durationMs": 3450,
  "outputTruncated": false,
  "verification": {
    "ok": true,
    "fails": [],
    "warns": [],
    "metrics": {
      "dimensions": [2.45, 1.82, 4.10],
      "center": [0.0, 0.0, 2.05],
      "pivotAtOrigin": true,
      "unappliedRotation": false
    }
  },
  "renders": {
    "view_front": "verify_visual/view_front.png",
    "view_side": "verify_visual/view_side.png",
    "view_top": "verify_visual/view_top.png",
    "view_perspective": "verify_visual/view_perspective.png"
  }
}

Why four views and not one: a single front shot hides depth errors — floating-vs-resting, behind-vs-in-front. A real case: chain links looked correctly attached from the front and were not attached at all when seen from the side.

Like every tool here it is a one-shot headless run: no add-on, no daemon, no socket.


9. General-Purpose Primitives (blender_locate & blender_run_script)

  • blender_locate: Resolves the active Blender executable on Windows, Linux, or macOS across explicit call parameters, environment variable BLENDER_EXE, standard installation paths (newest version first), and system PATH.

  • blender_run_script: Runs an arbitrary local Python script via blender --background --python <script.py> with optional arguments, timeout guardrail, and hard tail-buffer truncation (8 KB default, up to 50 KB max).


10. CI/CD Pipeline Integration (GitHub Actions)

Integrate headless asset QA directly into your GitHub Actions pull request checks to prevent broken FBX models, missing material slots, unapplied rotations, and displaced pivots from reaching the main branch:

name: 3D Asset QA Gate

on:
  pull_request:
    paths:
      - "assets/**/*.fbx"

jobs:
  verify-assets:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Install Blender & Node.js
        run: |
          sudo snap install blender --classic
          sudo apt-get install -y nodejs npm

      - name: Run Headless Asset Verification
        run: |
          npx -y ellmos-blender-use-mcp --version
          # Run structural FBX QA and 4-view visual verification
          blender --background --factory-startup --python node_modules/ellmos-blender-use-mcp/scripts/verify_asset_visual.py -- \
            --fbx assets/models/SM_HeroAsset.fbx \
            --out build/asset-qa/ \
            --json

11. Governance & Runtime Invariants

The server enforces 10 architectural and runtime invariants to guarantee privacy, safety, process isolation, and auditability:

ID

Invariant

Guarantee & Implementation Details

INV-LOCAL-01

100% Local-First & Zero Network Egress

Zero outbound network requests, external telemetry, or remote API calls. Runs fully air-gapped on the host machine.

INV-HEADLESS-02

Stateless & Add-on-Free Headless Execution

No Blender add-on installation, no open TCP sockets or daemon listeners, and zero mutation of the host Blender user directory.

INV-SEC-03

Non-Elevation & Unprivileged RunAsInvoker

Operates strictly with unprivileged user-mode permissions (RunAsInvoker). Never requires or requests administrative elevation.

INV-BOUND-04

Strict Timeout & Tail-Buffer Bounding

Every execution is timeout-guarded. Standard output and error streams are captured into bounded tail buffers (default 8 KB, max 50 KB), preventing runaway memory.

INV-INTEG-05

Deterministic JSON & Evidence Integrity

Produces verifiable, machine-readable JSON reports containing exact mesh counts, material slots, naming prefixes, and geometry metrics.

INV-VISUAL-06

Four-View Multi-Angle Visual Verification

Generates orthogonal front, side, top, and perspective renders to detect geometry defects (floating parts, unapplied rotation) that depth-blind checks miss.

INV-CLEAN-07

Fail-Closed Ephemeral Staging & Script Cleanup

Ephemeral Python verification scripts and temporary staging files are unconditionally purged from the filesystem upon completion or failure.

INV-CROSS-08

Cross-Platform Operating System Parity

Uniform execution and automated discovery across Windows, Linux, and macOS without hardcoded host dependencies.

INV-SYNC-09

Cloud-Sync & Multi-Host Lock Discipline

Resilient against cloud synchronization conflicts (*-conflict-*, *-CONFLIT-*) and compliant with canonical multi-agent locks.

INV-SLA-10

48h Security Response & 5-Day Triage SLA

Formal vulnerability acknowledgment within 48 hours and triage commitment within 5 business days via official coordination channels.


12. Security Policy & RunAsInvoker

  • Local Python Execution: This server runs local Python inside Blender. Use only scripts and asset paths you trust.

  • RunAsInvoker Non-Elevation: Runs strictly under standard unprivileged user accounts; no administrator or root privileges required.

  • Process Cleanup: Subprocesses are supervised; Windows processes are cleanly killed via taskkill /pid <PID> /T /F on timeout.

  • Offline Assurance: No remote asset marketplaces, external APIs, or usage telemetry are involved.

  • Vulnerability Disclosure: Review SECURITY.md for official coordination contacts and our binding 48-hour response SLA.


13. Installation & Getting Started

Option 1: Run via npx (no install)

{
  "mcpServers": {
    "blender-use": {
      "command": "npx",
      "args": ["-y", "ellmos-blender-use-mcp"]
    }
  }
}

Option 2: Install from source

git clone https://github.com/ellmos-ai/ellmos-blender-use-mcp.git
cd ellmos-blender-use-mcp
npm install
npm run build
node src/index.js

For a local checkout, point command/args at the cloned src/index.js instead:

{
  "mcpServers": {
    "blender-use": {
      "command": "node",
      "args": ["<path-to-repo>/src/index.js"]
    }
  }
}

14. Configuration & Environment

  • BLENDER_EXE — optional path to the Blender executable. Without it, tools try the explicit blenderPath argument, then BLENDER_EXE, then standard Blender install locations on Windows (%ProgramFiles%\Blender Foundation\Blender <version>\blender.exe and equivalent 32-bit and per-user roots, newest version first), then PATH. On Linux and macOS the lookup goes straight from BLENDER_EXE to PATH.

  • Every tool also accepts an explicit blenderPath argument per call, which takes priority over BLENDER_EXE.

  • Process output is retained only as a tail: blender_run_script defaults to 8,000 characters (configurable up to 50,000); FBX verification keeps 8,000. The response marks outputTruncated: true when earlier output was discarded, so verbose Blender scripts cannot grow the MCP process memory without bound.


15. Third-Party Licenses & Level 1 SBOM

All runtime production dependencies are distributed under permissive open-source licenses (MIT and BSD-2-Clause) with 0% copyleft:

  • @modelcontextprotocol/sdk (MIT)

  • update-notifier (BSD-2-Clause)

  • zod (MIT)

For the complete dependency inventory, Invariant Cross-Reference Matrix, and prior-art isolation analysis, see THIRD_PARTY_LICENSES.md.


16. Sibling Projects & ellmos-ai Ecosystem

This MCP server is part of the ellmos-ai ecosystem — AI infrastructure, MCP servers, and intelligent tools.

MCP Server Family

Server

Tools

Focus

npm

FileCommander

46

Filesystem, process management, interactive sessions, cloud-lock-safe operations

ellmos-filecommander-mcp

CodeCommander

22

Code analysis, JSON repair, imports, diffs, regex

ellmos-codecommander-mcp

Clatcher

12

File repair, format conversion, batch operations

ellmos-clatcher-mcp

n8n Manager

18

n8n workflow management via AI assistants

n8n-manager-mcp

ControlCenter

20

MCP stack discovery, profile management, control plane

ellmos-controlcenter-mcp

Homebase

45

Local-first LLM memory, knowledge, state, routing, swarm orchestration

ellmos-homebase-mcp (alpha)

ServerCommander

8

Server operations: health checks, log analysis, deploy dry-runs, mail diagnostics

ellmos-servercommander-mcp (alpha)

Blender Use

4

Headless Blender asset QA: structural FBX reimport checks and four-view visual verification

ellmos-blender-use-mcp (alpha)

Open Compute

10

Model-agnostic computer use: capture, safety-gated actions, Windows UIA

open-compute-mcp (alpha)

AI Infrastructure & Developer Tools

Project

Description

workflowhooker

Transparent command interceptor & safety sandbox for agentic workflows

system-explorer

System inspection, MCP orchestration, and fleet introspection runtime

memoryhooker

High-performance episodic memory interceptor for AI agents

policy-registry

Policy distribution and compliance engine for multi-agent frameworks

ellmos-delegation-authority

Trust boundary verification & cryptographic token delegation authority

sqlite-transit-sync

Transactional SQLite transit replication with snapshot isolation

BACH

Local-first text-based OS for LLM agents — 113+ handlers, 550+ tools, SQLite memory

open-compute

Model-agnostic computer-use core powering Open Compute MCP

clutch

Provider-neutral LLM orchestration with auto-routing and budget tracking

rinnsal

Lightweight agent memory, connectors, and automation infrastructure

ellmos-stack

Self-hosted AI research stack (Ollama + n8n + Rinnsal + KnowledgeDigest)

MarbleRun

Autonomous agent chain framework for Claude Code

gardener

Minimalist database-driven LLM OS prototype (4 functions, 1 table)

ellmos-tests

Testing framework for LLM operating systems (7 dimensions)

Desktop Software Suite & Sibling Tools

Our partner organization open-bricks bundles AI-native desktop applications and developer utilities — a modern, open-source software suite built for the age of AI:

Project

Ecosystem

Description

ProFiler

file-bricks

Advanced file management, deep inspection, and batch pipeline workbench

DokuZen

doc-bricks

Unified document converter, markdown formatter, and documentation hub

PDFtoPDFocr

doc-bricks

High-fidelity OCR processor and searchable PDF pipeline

FormularErstellen

doc-bricks

Declarative form generator and PDF schema compiler

MediaBrain

file-bricks

AI-assisted media categorization, tagging, and asset management

TextBrain

doc-bricks

Text analysis, summarization, and local language intelligence suite

knowledgedigest

open-bricks

Knowledge extraction, semantic clustering, and synthesis engine

DevCenter

dev-bricks

Developer environment orchestration and multi-agent management cockpit

CodeBox

dev-bricks

Secure execution sandbox and isolated code-runner runtime

BattleStage

entertain-and-more

Modular tactical game arena with automated asset pipeline validation


17. LLM Context Index (llms.txt)

For AI assistants and LLM tooling, llms.txt provides machine-readable architecture documentation, tool descriptions, search phrases, and runtime invariants.


18. License & Statutory Disclaimer (§ 521 BGB)

License & Attribution

Distributed under the MIT License. See LICENSE and NOTICE for full copyright and attribution details.

Statutory German Disclaimer (§ 521 BGB Gefälligkeitsrecht)

This open-source package is provided free of charge without consideration (Gefälligkeit). Under statutory German law (§ 521 BGB), liability for defects in quality and title is strictly limited to intentional misconduct (Vorsatz) and gross negligence (grobe Fahrlässigkeit).

Security Response Commitment

Security vulnerabilities are triaged within 48 hours under our binding Security SLA. Refer to SECURITY.md for coordinated disclosure guidelines.

Available Tools

3 tools
blender_locateC

Resolve the local Blender executable used for background automation.

ParametersJSON Schema
NameRequiredDescriptionDefault
blenderPathNo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description must fully disclose behavior. It states only that the tool 'resolves' an executable, but does not explain whether it searches system paths, how it handles the optional blenderPath parameter, what happens if Blender is not found, or what the return value looks like. This lack of detail leaves significant behavioral ambiguity.

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 a single, tightly worded sentence that immediately states the core purpose. It is appropriately sized and front-loaded with the key action ('Resolve'), with no wasted words or redundant detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has low complexity (one optional parameter, no output schema), making it feasible for the description to be complete. However, it omits crucial details: what the parameter does, what the tool returns, and error behavior. While the purpose is clear, the description is too skeletal for an agent to invoke the tool correctly in a real workflow.

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

Parameters1/5

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

The input schema contains one parameter, blenderPath, with no description in the schema (schema coverage 0%). The tool description does not mention this parameter at all, so it fails to explain its purpose (e.g., whether it is an override or a hint). With low schema coverage, the description must compensate, and it does not.

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 clearly states the tool resolves the local Blender executable, using a specific verb ('Resolve') and resource ('local Blender executable'). It distinguishes itself from siblings like blender_run_script and blender_verify_fbx_reimport by focusing on locating the executable rather than executing or verifying.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool or how it relates to the sibling tools. The phrase 'used for background automation' vaguely implies a setup/prerequisite step, but there is no mention of alternatives, exclusions, or typical workflow placement.

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

blender_run_scriptB

Run Blender in background mode with an explicit Python script and optional script arguments.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNo
timeoutMsNo
scriptArgsNo
scriptPathYes
blenderPathNo
outputTailCharsNo

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'background mode' but does not disclose potential side effects, output handling, error behavior, timeout implications, or whether the script execution is blocking. This is insufficient for a tool that runs arbitrary scripts and could have significant side effects.

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 a single, front-loaded sentence that conveys the core functionality without any wasted words. It is appropriately concise for the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters, no annotations, and no output schema, the description is incomplete. It does not explain how output is returned, the meaning of timeoutMs, cwd, blenderPath, or outputTailChars, nor does it mention any constraints or side effects. The description provides only a surface-level understanding, which is inadequate for a tool with this complexity.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only mentions 'explicit Python script' and 'optional script arguments', which loosely map to scriptPath and scriptArgs, but it completely omits cwd, timeoutMs, blenderPath, and outputTailChars. The description adds minimal meaning beyond the parameter names and fails to explain the purpose of most parameters.

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 clearly states the tool runs Blender in background mode with an explicit Python script and optional script arguments. It specifies the action (run), the resource (Blender), and the mode (background), which distinguishes it from sibling tools like blender_locate (locating Blender) and blender_verify_fbx_reimport (verifying FBX reimport).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its usage by saying 'Run Blender in background mode with an explicit Python script', but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. There is no mention of prerequisites or conditions for use, so it remains implied rather than explicitly guided.

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

blender_verify_fbx_reimportC

Import an FBX in headless Blender and write/read a JSON verification result.

ParametersJSON Schema
NameRequiredDescriptionDefault
fbxPathYes
timeoutMsNo
resultPathNo
blenderPathNo
requiredPrefixesNo

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of disclosing side effects and runtime behavior. It mentions headless Blender and file I/O, but omits external dependencies, error cases, and what the verification result contains.

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 a single sentence with no filler, front-loading the primary action and result. It is appropriately concise for the amount of information it conveys.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a tool with five parameters, no output schema, and no annotations, yet the description is only a vague one-liner. It does not explain return values, parameter semantics, or the meaning of the verification result, making it insufficient for correct invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention or explain any of the five parameters. Required fields like fbxPath and optional parameters like resultPath and requiredPrefixes are completely undocumented.

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 uses a specific verb ('Import') and a specific resource ('FBX in headless Blender'), and clearly indicates the JSON verification output. This distinguishes it from siblings like blender_locate and blender_run_script, which target different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus the sibling tools, nor does it mention any alternatives or exclusions. It simply states the action without placement in a workflow.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0-alpha.7
    • First observedblender_locate
    • First observedblender_run_script
    • First observedblender_verify_fbx_reimport

TDQS

B3.3/5.0

Scored across 3 tools

Disambiguation4/5

Each tool has a distinct purpose: locating the executable, running a script, and verifying FBX re-import. The only slight overlap is that verify_fbx_reimport is a specialized form of run_script, but the descriptions clarify their intended uses.

Naming Consistency5/5

All tool names follow a consistent 'blender_<verb>...' pattern (locate, run_script, verify_fbx_reimport). The naming convention is uniform and predictable.

Tool Count5/5

With only 3 tools, the set is tightly scoped to Blender automation workflows. Each tool serves a clear and necessary function, and the count is well within the expected range for a focused utility server.

Completeness3/5

The toolset covers the core workflow of locating Blender, running scripts, and verifying FBX files, but lacks generic ways to retrieve script output or handle other common Blender operations. This leaves some gaps for broader automation scenarios.

Maintenance

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    A
    quality
    C
    maintenance
    A headless-first Model Context Protocol server for safe, deterministic Blender automation, exposing typed tools to inspect scenes and render previews without arbitrary command execution.
    3
    -
  • A
    license
    A
    quality
    C
    maintenance
    Enables safe, repeatable preparation of game characters in Blender through high-level MCP tools for validation, import, normalization, action renaming, and GLB export, with dry-run by default and loopback-only security.
    9
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Enables safe, structured control of Blender on Windows via a standalone STDIO MCP server, providing seven tools to inspect scenes, list and edit materials, transform objects, add modifiers, set smooth shading, and export assets without arbitrary code execution.
    7
    Apache 2.0
  • A
    license
    D
    quality
    A
    maintenance
    Enables Blender automation via MCP with 107 tools for complex mesh modeling, PBR texturing, UV mapping, rigging, animation, lighting, rendering, and a pre-export curing pipeline for Godot 4.x/Redot GLB export.
    107
    GPL 3.0