Skip to main content
Glama
TFMSTYLE

tfmstyle-blender-tools

by TFMSTYLE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Blender Agent Tools

One MCP toolbox that lets any agent use the TFMSTYLE Blender addons inside a running Blender.

This is a prototype. It covers Rock, Orbiter and Graph. The other addons join as they pass the same test.

The three tools

Tool

What it does

list_addons

The TFMSTYLE addons running in Blender, with their versions

describe_addon

One addon's actions and settings, with current values and allowed ranges

run_addon

Applies settings, runs an action, or both

Settings and ranges are read from Blender at the moment of the call, so nothing about any addon is kept here. Nothing is installed in Blender, and the addons themselves do not change.

run_addon checks everything first, and one bad value refuses the whole call. It only runs an addon's own actions. It leaves out anything that imports, exports, opens a file or goes online, and an action that clears or resets something needs confirm=true.

Related MCP server: Frugal Blender MCP

What you need

  • Blender 5.1 or newer, with the TFMSTYLE addons you want enabled, separately or through the Addon Collection

  • The MCP add-on from Blender Lab, enabled with its server started

  • Python 3.10 or newer

Blender Lab warns that its server runs agent written code with no guards. The checks here cover these three tools only. They do not limit what an agent can do through Blender Lab's own tools.

Install

pip install git+https://github.com/TFMSTYLE/Blender_Agent_Tools.git

Then add it to your MCP client. For most clients:

{
  "mcpServers": {
    "tfmstyle-blender-tools": {
      "command": "tfmstyle-blender-agent-tools"
    }
  }
}

It uses the same BLENDER_MCP_HOST and BLENDER_MCP_PORT settings as Blender Lab's server, and both can run at once.

With no window

Background Blender works too, with blender --background --online-mode --command blender_mcp. Actions that keep running, like Orbiter's orbit, are refused there because they need an open window.

Test

python tests/live_test.py <folder with the three zips> <collection zip>

It starts throwaway Blenders with their own settings folder and port, and drives them through a real MCP connection. A Blender you have open is left alone.

License

GPL 3.0 or later.

Available Tools

3 tools
describe_addonB
Read-only

Show one addon's actions and settings, with current values and allowed ranges.

Settings kept per item appear under lists, for example one set per saved graph. Set those with the name list[index].setting.

NameRequiredDescriptionDefault
addonYes

TDQS

B3.4/5.0
Behavior4/5

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

The readOnlyHint annotation already establishes the safety profile. The description adds useful behavioral context beyond that: it says the result includes actions, settings, current values, allowed ranges, and per-item `lists` structure. It does not cover auth, errors, or rate limits, but it contributes meaningful detail beyond the annotation.

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?

The description is short and front-loaded, with the core purpose in the first sentence. The second paragraph adds relevant information about `lists`, though the sentence about setting values is slightly awkward for a read-only describe tool.

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

Completeness3/5

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

There is no output schema and no schema description for the only parameter, so the description carries more burden. It explains the general return concepts and the `lists` structure, but it does not specify how to identify the addon or fully describe the response shape.

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?

There is one required parameter, `addon`, with 0% schema description coverage, so the description needs to compensate. It refers to 'one addon' but never explains the expected identifier format, accepted values, or how to obtain a valid addon name, leaving the parameter largely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Show') and resource ('one addon's actions and settings'), and it states the scope includes current values and allowed ranges. It implies a single-addon lookup versus the sibling list_addons, but it does not explicitly name or differentiate against siblings.

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 this is for inspecting an addon's settings and allowed values, and it explains how per-item settings appear under `lists`. However, it gives no explicit when-to-use guidance, no exclusions, and no comparison to list_addons or run_addon.

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

list_addonsA
Read-only

List the TFMSTYLE addons running in Blender, with their versions.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read, and the description adds that results include versions. Beyond that it discloses nothing new: no indication of ordering, whether disabled addons are included, or what happens when Blender is unavailable, which matters since there is no output schema.

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?

A single short sentence, front-loaded with the verb and resource, with no filler. Every clause (TFMSTYLE scope, running, versions) carries information.

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

Completeness4/5

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

With no parameters and no output schema, the description does the important work of stating what comes back (addons plus versions) and that only running addons are listed. Minor gaps remain around ordering and error behavior, but nothing essential for correct invocation 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema coverage is also 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ("List the TFMSTYLE addons") plus scope and return content ("with their versions"). It doesn't explicitly name describe_addon or run_addon, but the list/describe/run split is inferable from the wording.

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?

Usage is only implied: an agent can infer it should call this to enumerate addons before calling describe_addon or run_addon on one of them. There is no explicit when-to-use or when-not-to-use statement, and no prerequisites mentioned.

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

run_addonA
Destructive

Apply settings to an addon, run one of its actions, or both.

Everything is checked first: one bad value refuses the whole call and changes nothing. An action that clears or resets something needs confirm=true. Settings stay as set, the same as if a person had moved the slider.

NameRequiredDescriptionDefault
addonYes
actionNo
confirmNo
settingsNo

TDQS

A3.6/5.0
Behavior4/5

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

Adds real behavior beyond the destructiveHint annotation: the call is atomic ('one bad value refuses the whole call and changes nothing') and settings persist as if a person moved the slider. The destructive path is flagged but the description doesn't spell out what exactly gets destroyed or reset.

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?

Three short paragraphs with the core capability front-loaded and the validation/confirm caveats following. No filler, though the trailing settings-persistence sentence is slightly tangential.

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

Completeness3/5

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

For a destructive, four-parameter tool with no output schema and minimal annotations, the description covers atomicity and confirm but omits what a successful call returns, how to discover valid action names, and what 'clearing or resetting' means concretely.

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 coverage is 0%, so the description must carry the load. It explains confirm (required for clearing/resetting actions) and settings (persisted), but says nothing about the required 'addon' identifier format or where valid 'action' values come from — two of four parameters remain unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: apply settings, run an action, or both, on an addon. This clearly separates it from list_addons and describe_addon, which are read-only siblings, though it never names them explicitly.

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?

Gives one concrete usage rule ('an action that clears or resets something needs confirm=true'), which is genuinely useful. However, it never says when to call this instead of describe_addon first, or whether action names must be discovered through a sibling, leaving the main selection decision implied.

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
    • First observeddescribe_addon
    • First observedlist_addons
    • First observedrun_addon
Deploy Server
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

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: list_addons enumerates addons, describe_addon inspects one addon's actions/settings, and run_addon applies settings or executes actions. There is no meaningful overlap in purpose, and the descriptions make the boundaries clear.

Naming Consistency5/5

All three tools follow a consistent verb_noun pattern: list_addons, describe_addon, run_addon. The naming is predictable and easy to map to the intended operations.

Tool Count5/5

Three tools are well-scoped for a server focused on managing TFMSTYLE Blender addons: one to enumerate, one to inspect, and one to act. Each tool earns its place without redundancy.

Completeness4/5

The surface covers the core lifecycle of discovering addons, inspecting their settings/actions, and running them with validation and confirmation. Minor gaps exist, such as enabling/disabling addons or viewing logs, but core workflows are covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers