Loading ToolBench
SQL interface to bpy.data for AI agents. Exposes the running Blender as a SQL database via HTTP and MCP endpoints.
BlenderSQL defines 6 tools with complete JSON schemas and clear descriptions. All tools have proper input schemas with type definitions and required fields. Descriptions are substantive (100-250 chars), explaining what each tool does and when to use it. Tool names follow verb_noun convention (query, execute, list_tables, describe_table, list_functions, describe_function). However, parameter descriptions are minimal or absent in some cases (e.g., 'sql' param lacks format/constraint guidance). Output schemas are documented in descriptions but not formally specified in the tool definitions. Error handling is mentioned but not detailed. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata.
Return parameter signature for one SQL scalar function from `bsql_function_params`: position, name, type, required, default_json, hint. Probes `bsql_functions` first so typo'd names surface as `unknown function: <name>`.
Return column info for one virtual table from `bsql_columns`: name, type, writable, pk, identifier, insert_only, hint. Probes `bsql_tables` first so typo'd / wrong-case names surface as `unknown table: <name>`.
Run any SQL — including writes and side-effecting function calls (bpy_eval, bpy_exec, bpy_op, typed verbs like add_object, save, render, ...). Use `list_functions()` to discover available functions. Returns the same JSON shape as query().
List BlenderSQL SQL scalar functions usable inside `execute(...)`. Sourced live from `bsql_functions`: name, kind (escape_hatch / verb / scalar), arity (-1 = variadic), description. Use describe_function(name) to see a function's parameters.
List every virtual table in the running Blender's SQL schema. Sourced live from `bsql_tables`. Returns columns [name, writable, domain, description]. `writable=1` means the table accepts INSERT/UPDATE/DELETE directly via `execute`. Use describe_table(name) for per-column detail.
Parameter descriptions lack format/constraint guidance. 'sql' parameter in query() and execute() does not specify allowed SQL dialects, statement types, or size limits. LLMs cannot infer whether to pass raw SQL or escaped strings.
No tool annotations despite explicit risk classifications. query() and list_* tools are READ_ONLY; execute() is DESTRUCTIVE. MCP spec supports readOnlyHint and destructiveHint annotations, these should be present to guide agent safety policies.
Output schemas documented in descriptions but not formally specified. Tool descriptions mention JSON return shape {ok, columns, rows, row_count, duration_ms} but no structured output schema is declared in tool definitions. LLMs cannot reliably parse responses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Run a read-only SQL query against the running Blender. Accepts SELECT / WITH / PRAGMA / EXPLAIN. Writes (INSERT/UPDATE/DELETE, function calls with side effects) are rejected — use `execute` for those. Returns JSON: {ok, columns, rows, row_count, duration_ms} on success; {ok: false, error: ...} on failure.
Error handling guidance is implicit. Descriptions mention {ok: false, error: ...} format but do not explain error categories (retryable vs fatal) or recovery steps. LLMs lack actionable error recovery paths.
No pagination or result limits documented. list_tables() and list_functions() return all results without documented limits. If Blender has hundreds of tables/functions, responses could exhaust context windows.