Loading ToolBench
MCP server with MCP Apps integration for Gaussian splat visualization and generation
The server defines 3 tools with clear action verbs and descriptive text. Tool names follow verb_noun convention (generate-, open-, view-). Descriptions are present and contextual, ranging 80-280 characters. However, schema completeness varies significantly. The generate-splat-from-image tool has rich, well-structured input schemas with descriptions for all parameters and proper enum constraints. The open-ply-upload tool has an empty input object ({}), which is valid but offers no guidance. The view-ply-splat tool has nullable string parameters that lack format constraints. Output schemas are not documented anywhere in the codebase, the tools return structured widget/text responses via the mcp-use framework, but the output shape is never formally declared for LLM consumption. Error handling is present in code (try-catch, validation, logging) but error responses lack recovery guidance, they return generic 'error()' calls without actionable next steps. No tool declares security implications, and no input validation is visible for untrusted sources (the modalInferenceClient and file resolution appear to be internal services without clear bounds checking).
Generate a new gaussian splat PLY from exactly one input image using Modal SHARP inference, then render it. Use this only when the user explicitly wants image-to-splat generation. If no image source exists yet, call open-ply-upload so the user can upload an image.
Primary entrypoint for Splatter when no direct URL is provided. Opens a widget where the user can upload either a Gaussian splat .ply file (render directly) or an image (generate a splat, then render).
Render a .ply gaussian splat when a source is already available (URL or attachment reference). If the user has no source yet, call open-ply-upload so they can upload a local .ply.
Output schemas not documented. Tools return widget() and text() objects, but the LLM never sees the declared structure of widget props (SplatViewerProps). LLMs need documented output schemas to plan downstream calls and extract necessary fields.
Error responses lack recovery guidance. When errors occur (e.g., validateLikelyGaussianSplatPly fails, or modalInferenceClient times out), the code returns error() with a generic message. LLMs cannot act on bare errors without 'what to do next', e.g., 'Invalid PLY format. Ensure the image is a photograph, not a diagram. Retry with a different image.'
open-ply-upload has an empty input schema ({}). While technically valid for a zero-parameter tool, this prevents LLMs from influencing behavior, e.g., pre-selecting upload type (ply vs image), setting display name, or configuring inference tier. Consider adding optional parameters to guide tool behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 62 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Parameter constraints are incomplete. uploadReference and plyUrl are string|null but do not specify URL format (RFC 3986), length limits, or encoding expectations. GPU tier enum is constrained, but sourceType enum values are not visible in the schema spec (referenced but not defined).
No security scopes declared. Tools interact with external inference services (Modal SHARP), file attachment resolution (OpenAI), and artifact storage. No documentation of what permissions these tools require (e.g., 'write:artifacts', 'read:openai-files', 'execute:modal-inference'). Agents cannot be configured with least-privilege access.
Idempotency not guaranteed for generate-splat-from-image. The tool generates a new splat each time, even with identical input, no deduplication, caching, or idempotent key support. If an LLM retries due to an ambiguous failure, a duplicate splat is created. Consider adding an optional 'generation_id' or 'idempotency_key' parameter.