Loading ToolBench
Expose SceneForge's pipeline as MCP tools, so an agent can drive image -> 3D-scene generation as a step in a larger workflow, instead of only via shelling out to cli.py.
SceneForge has 5 tools with clear verb-noun naming (start_pipeline, check_job_status, get_viewer_path, list_jobs, check_environment). All tools have descriptions (avg 180 chars, within 10-1024 range). Input schemas are present with type definitions for all parameters. However, parameter descriptions are sparse or missing in several tools (e.g., list_jobs and check_environment have empty input objects with no descriptions). Output schemas are not documented, LLMs cannot infer what fields to expect from responses. Error handling is minimal; no recovery guidance or actionable error messages. The tool composition is reasonable (single responsibility per tool), but missing output documentation and parameter descriptions for discovery tools significantly limits LLM usability.
Check whether COLMAP and OpenSplat binaries are available, and whether a GPU is detected. Useful for an agent to sanity-check the environment before calling start_pipeline, rather than discovering a missing binary partway through a long run.
Poll the status of a pipeline job started with start_pipeline. Returns: dict with status (pending/running/completed/failed/aborted), error message if applicable, and any warnings logged during the run (e.g. low match quality, no GPU detected, too few images).
Get the path to the generated viewer.html for a completed job. Returns an error if the job hasn't completed yet -- call check_job_status first to confirm status == "completed".
List all known jobs (this server process's lifetime only) and their status.
Start the SceneForge pipeline (fetcher -> validator -> COLMAP -> OpenSplat -> viewer) in the background and return immediately. This does NOT block -- use check_job_status(job_id) to poll progress. The pipeline can take from minutes (COLMAP only) to hours (CPU OpenSplat training) depending on image count, iterations, and whether a GPU build of OpenSplat is available.
Output schemas not documented. LLMs cannot infer what fields check_job_status, get_viewer_path, list_jobs, and check_environment return. This forces agents to guess at response structure and breaks downstream tool chaining.
Discovery tools (list_jobs, check_environment) have empty input schemas with no parameter descriptions. While technically valid (no required params), the lack of any documentation about what these tools reveal or when to call them reduces discoverability.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., start_pipeline could fail if images_dir doesn't exist, but no recovery hint is provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
start_pipeline accepts a 'force' parameter but does not document the consequences of setting it to true. LLMs need to know this will re-run all stages and discard checkpoints, which is a destructive operation.
No pagination or result limits documented for list_jobs. If many jobs accumulate, the response could grow unbounded and exhaust context windows.