Skip to main content
Glama
LandgrafRalle

toolbag-mcp

by LandgrafRalle
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Related Servers

Alternatives to toolbag-mcp

No user-submitted related servers found.

    Related Servers

    • dcc-mcp-marmoset

      dcc-mcp
      A
      license
      Not graded
      quality
      A
      maintenance
      Typed DCC-MCP control for Marmoset Toolbag 4.03+ and 5.x, enabling shell-capable agents to interact with Toolbag scenes via a shared CLI and MCP gateway.
      3
      MIT

    • blendermcp

      ZNaiGaomu
      A
      license
      C
      quality
      B
      maintenance
      Enables secure, local automation of Blender through typed MCP tools for scene, modeling, material, animation, rendering, and file workflows via an authenticated loopback bridge.
      173
      MIT

    • Ruin's BlockBenchMCP

      Ru1n-dev
      F
      license
      Not graded
      quality
      B
      maintenance
      Enables MCP clients to drive Blockbench Desktop locally for Minecraft model, UV, texture, animation, and export workflows. It provides typed operations, high-level task workflows, native controls, and inspection/verification tools over an authenticated loopback connection.
      3
      -

    • omni-kit-mcp

      inbarajaldrin
      A
      license
      A
      quality
      D
      maintenance
      Enables driving Omniverse Kit apps (Isaac Sim, Isaac Lab) over MCP, allowing agents to control simulations, run Python, and call namespace-scoped tools via a single bridge.
      1
      2
      MIT

    • blender-ai-mcp

      alexandervi1
      A
      license
      Not graded
      quality
      D
      maintenance
      Connects MCP-compatible clients to a live Blender scene for AI-assisted 3D workflows, enabling inspection and controlled operations on objects, materials, cameras, lights, render settings, animation, UVs, Geometry Nodes, imports, exports, and Python execution.
      1
      MIT
    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

    B3.2/5.0

    Scored across 93 tools

    Disambiguation4/5

    Tools are organized into clear domain prefixes (scene_, object_, material_, baker_, camera_, sky_, fog_, render_, timeline_), so most selections are obvious. A few genuine overlaps exist: object_create vs light_create/camera_create, object_set_attributes vs camera_set/sky_set, and scene_list_objects vs object_find vs scene_tree; descriptions mostly disambiguate (e.g. object_set_visible explicitly defers to baker_set_visible/baker_isolate for bake scenes), but the create/attribute-set duplication could still cause misselection.

    Naming Consistency4/5

    The dominant convention is prefix_noun_verb (material_set_texture, baker_set_maps, camera_set_active), applied consistently across domains. Deviations are limited to a handful of bare or legacy names (status, capabilities, execute_python, toolbag_quit), which are readable but break the pattern.

    Tool Count2/5

    93 tools is far beyond any comfortable agent working set, even for a full 3D DCC application. The breadth (baking, skew masks, sky, fog, render, timeline) justifies many of them, but a large tail of hyper-specific tools (baker_skew_preview/apply/clear_preview, baker_map_path, camera_post_effect_file, baker_set_udim_tile) bloats the surface when execute_python could absorb rare cases.

    Completeness5/5

    Coverage is exceptional: full lifecycle for scenes, objects, materials, bake projects, cameras, sky, fog, lights, rendering, and timeline, plus presets and export paths. The execute_python escape hatch means there are effectively no dead ends for operations the tool set omits (e.g. material renaming).

    Maintenance

    ActivityMaintained
    ResponsivenessNo issues

    Resources