Loading ToolBench
MCP server for DreamFX and DreamShader - routes AI tooling to a warm Unreal editor, or falls back to the CLI
dream-mcp defines 2 tools with complete input schemas and descriptions. Both tools are READ_ONLY and well-documented for their narrow domain (DreamFX/DreamShader introspection). Naming follows verb_noun convention (dream_status, dream_schema). Descriptions are detailed (200+ chars) and explain WHEN to use each tool. However, output schemas are not formally documented, responses are free-form strings rather than structured objects. Error handling is minimal (basic try/except with string messages). No parameter validation, enums, or constraints beyond type declarations. The tools are discovery/read-only, so composition and idempotency concerns are low-risk, but output structure limits downstream agent reasoning.
Look up the real signature of a DreamFX module / dynamic input, or a DreamShader material expression, Substrate builtin or enum alias. Reads cached manifests off disk -- no editor, no bridge, milliseconds. Use it instead of guessing an input name or reading one off a design document: modules get revised, and a wrong name fails the build with DFX3003. name: a bare name (GravityForce), a full path, or any tail of one (Spawn/Initialization/InitializeParticle -- anchored at the end, so it selects that asset and not its V2/ sibling). Ambiguous short names are refused with the full candidate list rather than resolved arbitrarily. lang: "fx", "shader", or "auto" to try DreamFX first and fall back to DreamShader. kind: optional filter -- "module" or "dynamicInput" for fx.
Report whether a warm Unreal editor is available for DreamFX / DreamShader work. Use this before any build or compile: a live editor serves requests in the time the work takes, while the CLI pays a 12-24 s engine boot, and running the CLI while an editor holds the same packages open causes a silent double-write where the later save wins. Also reports the cached module index and manifests that dream_schema reads.
Output schemas not documented. Both tools return free-form strings (str) rather than structured objects. LLMs cannot parse or chain results reliably. dream_status returns multi-line status text; dream_schema returns formatted module/expression details as plain text. No field definitions, no typed response structure.
dream_schema accepts 'lang' and 'kind' parameters without enum constraints. 'lang' should be constrained to ['fx', 'shader', 'auto']; 'kind' to ['module', 'dynamicInput']. Free-form strings invite hallucinated values.
Error handling is minimal. dream_status catches LocateError and returns a string message; dream_schema has no visible error handling in the provided code. No guidance on recovery (e.g., 'Try calling dream_status first to verify project setup'). Errors are not categorized as retryable vs. fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
No input validation or constraints documented. dream_schema's 'name' parameter accepts any string; no guidance on format (bare name vs. full path vs. tail match). dream_status's 'project_dir' is optional but no default behavior documented.
STDIO transport only. Server is not remotely accessible and cannot be used by hosted MCP clients. Limits deployment flexibility and testing surface.