Live observability, guided skills, and an agent (MCP) surface for Blender -> glTF asset pipelines
Hologram provides 5 tools with clear, domain-specific names (list_assets, inspect_asset, tail_events, pipeline_status, render_asset) that follow verb_noun conventions. Descriptions are present and substantive (100-300 chars), explaining what each tool does and when to use it. However, input schemas lack proper JSON Schema type definitions, parameters are documented in descriptions but not formally typed in the schema structure. Output schemas are documented in descriptions but not formally declared. Error handling is mentioned (e.g., render_asset returns structured error dicts) but recovery guidance is minimal. The render_asset tool is marked WRITE but lacks confirmation/dry-run patterns. Overall, definitions are above-average for community servers but fall short of production-grade rigor.
Parse a single GLB into Hologram's flat Asset structure. Args: path: Path to the .glb (absolute, or relative to the project root or export_root). Must resolve inside the project. Returns: The Asset as JSON: nodes (hierarchy with parent/children/mesh/skin/ translation/extras), roots, top_level_nodes, animations, materials, mesh_names, skins, and counts. On failure: {"error": str, "path": str}.
List exported GLB assets, grouped by the categories defined in hologram.toml. Args: category: Optional category name to filter to. If omitted, every configured category is returned. Projects with no [categories] expose a single "all" category. Returns: {"project": str, "root": str, "total": int, "categories": {name: [{"name", "glb", "mtime", "script"}, ...]}}
Summarize what's wrong with the pipeline right now — one read of the log. Aggregates, newest-first: * failures — recent failed tool calls, each with its error text * last_check — the most recent `hologram check` summary (assets / checks / errors / warnings) * recent_diffs — assets whose fingerprint changed since their last checkpoint (lost / gained / changed counts) Args: limit: How many recent events to scan, newest first (default 200). Returns: {"project", "failures", "failure_count", "last_check", "recent_diffs", "generated_at"}. Note: this reflects the *last emitted* check_run from the log; it does not run checks (the MCP server never imports user project code).
Render one GLB to PNG bytes via the live Blender instance (Move 1). Read-only toward the project and non-destructive toward Blender: ``blender.render_glb`` drives a throwaway scene in the running Blender and restores the user's scene afterward. We own the temp PNG it writes — read the bytes, then unlink. Never raises; on any failure (Blender unreachable / import error / timeout) returns a structured error dict with a hint.
Input schemas lack formal JSON Schema type definitions. Parameters are documented in descriptions but not declared with 'type' fields in the schema object. This forces LLMs to infer types from descriptions alone, increasing parsing errors.
Output schemas are documented in prose descriptions but not formally declared as structured JSON Schema. LLMs cannot reliably parse unstructured output descriptions to plan downstream tool calls.
render_asset is marked WRITE (destructive) but lacks confirmation/dry-run pattern. Agents cannot preview rendering before committing, risking unintended side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Return recent pipeline activity from the shared event log. Args: limit: Maximum number of events to return, newest first (default 50). Returns: {"events": [event dicts]}
Error handling descriptions mention structured error dicts but do not provide recovery guidance. E.g., render_asset says 'returns a structured error dict with a hint' but does not explain what the LLM should do next (retry, ask user, abort).
Parameter descriptions lack explicit constraints. E.g., 'limit' in tail_events and pipeline_status has no stated min/max bounds, allowing LLMs to pass unbounded values that could cause performance issues.