Loading ToolBench
Model Context Protocol server for FrameForge v2 — a document layout and rendering system. Provides tools for SDK code execution, document validation, rendering, and vision-based document generation.
FrameForge MCP has 11 tools with reasonable descriptions (avg ~150 chars), but critical gaps in schema completeness and parameter documentation. Most tools lack explicit input parameter type definitions and descriptions in the visible source. Tools like run_sdk_code and run_sdk_client accept code/path inputs but lack validation constraints, format specs, or error recovery guidance. Output schemas are not documented. The server exposes filesystem operations (read_file, write_file, list_directory) with path constraints via environment variables, but these constraints are not reflected in parameter descriptions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Error handling is minimal, no guidance on recovery, retryability, or actionable error messages.
Check whether fonts in a document will substitute at render time. Returns a report of missing fonts and their fallbacks.
Use a vision-language model to describe the visual content of a rendered document page. Requires the vlm dependency group.
List files and directories in a path (constrained to FRAMEFORGE_MCP_INPUT_ROOTS).
List all font families available in the runtime, with optional filtering by name or script support.
Generate a draft FrameForge document from an image or PDF page using computer vision and optional VLM analysis. Detects shapes, text, and layout structure.
Read a file from the filesystem (constrained to FRAMEFORGE_MCP_INPUT_ROOTS). Supports text and binary formats.
Render a FrameForge document to SVG, PNG, PDF, or LaTeX/TikZ. Supports multiple render engines (cairo, chromium, lualatex, pdflatex) with automatic engine selection.
Input parameter schemas lack type definitions and constraints. run_sdk_code accepts 'code' (string) and 'client_id' (string) but no format, length, or validation rules are documented. Enums for render_document's 'target' and 'engine' are present but other params lack constraints.
Output schemas are not documented. Tools return objects (e.g., render_document returns SVG/PNG/PDF) but the response structure, field names, and types are not specified. LLMs cannot plan downstream calls without knowing what fields to extract.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Execute a Python SDK client script from the filesystem. The script must define a build() function that takes a DocumentBuilder and returns a FrameForge document.
Execute Python SDK code in a sandboxed subprocess. The code receives a DocumentBuilder instance and must call builder.build() to return a FrameForge document. Supports imports from frameforge_sdk and standard library.
Structurally validate a FrameForge document against the Pydantic models. Returns detailed validation errors, warnings, and a pass/fail status.
Write a file to the filesystem (constrained to FRAMEFORGE_MCP_EDIT_ROOTS for code, or FRAMEFORGE_MCP_PUBLISH_ROOT for outputs). Supports text and binary formats.
Filesystem operations (read_file, write_file, list_directory) document path constraints via environment variables (FRAMEFORGE_MCP_INPUT_ROOTS, FRAMEFORGE_MCP_EDIT_ROOTS, FRAMEFORGE_MCP_PUBLISH_ROOT) but these constraints are not reflected in parameter descriptions. LLMs cannot infer valid paths without explicit guidance.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Agents cannot determine which tools are safe to retry, which modify state, or which are read-only without explicit hints. write_file and run_sdk_code are destructive but unmarked.
Error handling is minimal. No guidance on recovery, retryability, or actionable error messages. run_sdk_code and run_sdk_client execute untrusted code in subprocesses but do not document failure modes, timeout behavior, or how to interpret execution errors.