Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Three tools are explicitly defined with descriptions and partial input schemas. Naming follows the verb_noun pattern (build_, start_), which is good. However, critical deficiencies exist: (1) Parameter descriptions lack detail and constraints, most parameters are minimally documented without format/range guidance. (2) No output schemas are documented for any tool, LLMs cannot plan downstream calls or understand return structure. (3) Error handling is minimal, the code has internal error handlers but tool descriptions give no guidance on recovery. This server demonstrates basic competence in naming but falls short of production quality in parameter documentation, output specification, and error recovery guidance.
Tools (3)
build_sandbox_imagewritesource verified35/100
Builds the Docker image for the development sandbox.
This should be run once or after changes to the Dockerfile or
entrypoint.sh.
start_github_sandboxwritesource verified55/100
Starts a dev sandbox container by cloning a GitHub repository.
start_local_sandboxwritesource verified55/100
Starts a dev sandbox container by copying files from a local directory.
Changes inside the container will NOT affect the original host directory.
No output schemas documented for any tool. LLMs cannot understand return structure, required fields for chaining, or pagination support. This forces agents to guess at downstream tool compatibility.
Parameter descriptions are minimal and lack actionable constraints. 'Absolute path to the local directory' (local_dir) omits: Is it validated? What happens if it doesn't exist? What file types are supported? Must it be readable? No format or range guidance.
Document output schemas for all tools. Specify: (1) build_sandbox_image returns a success message and image name/ID; (2) start_local_sandbox and start_github_sandbox return container ID, container name, access URLs (http://localhost:3000, http://localhost:8080), and status. Include structured fields (e.g., {"container_id": string, "status": "running", "urls": {"app": string, "vscode": string}}).
Add explicit constraints to parameters. Example for local_dir: 'Absolute path to an existing, readable directory on the host system. Path must be accessible and contain project files. If the directory does not exist, this tool will fail with FileNotFoundError.' For node_packages: 'Comma-separated list of npm packages. Each package name must be a valid npm package (alphanumeric, hyphens allowed). Max 50 packages. Example: nodemon,eslint,prettier. If any package does not exist on npm, installation will fail and the container will exit.'
Replace example values in parameter descriptions with formal constraints. Change 'e.g., nodemon,eslint' to an enum or pattern declaration, or move the example to a separate 'Examples' section outside the description.
Add recovery guidance to tool descriptions. Example: 'If Docker is not installed, the tool will return a RuntimeError. Solution: Install Docker CLI on the host system and ensure it is in your system PATH. Then retry.' Pattern: [error type] -> [what to do next].
Document github_repo validation. Specify: 'Must be a valid GitHub repository URL (https://github.com/owner/repo.git or https://github.com/owner/repo). The repository must be public or the calling user must have credentials configured. If the repository is not found or is inaccessible, the tool will fail with an error message indicating the repo URL.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 3 points across a rubric change (v1 → v2)
39/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
39
<=2025-11-25
v2
2026-03-09
F
42
-
v1
node_packages parameter lacks constraint details. Description says 'comma-separated list' but provides no guidance on: valid package names, max count, allowed characters, or what happens if an invalid package is requested. Example 'nodemon,eslint' risks LLM reusing it literally.
Tool descriptions lack recovery guidance. No description explains: What are common failure modes? What should the LLM do if Docker is not installed? Should the agent retry? Can it be fixed by a different tool? Error handling is unidirectional.
start_github_sandbox accepts 'github_repo' as a free-form string with no validation visible in description. No mention of: must be a valid GitHub URL? Must the repo be public? What happens if the repo doesn't exist or is private? LLMs will hallucinate invalid URLs.
start_local_sandbox and start_github_sandbox share almost identical optional parameters (node_packages, initial_command) but no description explains their interaction, precedence, or whether both can be used together. Undocumented dependencies.
start_local_sandboxstart_github_sandbox
Add a section to start_local_sandbox and start_github_sandbox descriptions explaining: Can initial_command and node_packages be used together? What is the execution order? (e.g., 'Packages are installed before initial_command runs. Both can be specified together.').
For build_sandbox_image, add a non-empty schema specifying any optional parameters (e.g., dockerfile_path if Dockerfile location is configurable, or image_tag if custom tags are supported). Currently it accepts no parameters, but the description should be explicit: 'This tool takes no input parameters. It builds a Docker image from the bundled Dockerfile.'
Enhance error messages returned by tools to guide LLM recovery. Instead of raw RuntimeError, return structured messages: '{"status": "error", "type": "docker_not_found", "message": "Docker CLI not found. Please install Docker and ensure it is in your system PATH. Then retry.", "retryable": true}' to help LLMs decide whether to retry or ask the user.
Add pagination/result limits to any future list tools (e.g., if you add list_containers). Specify: 'Returns max 50 containers. Use limit and offset parameters for pagination. Always returns a total_count field.'
Document platform-specific behavior. The code calls _get_uv_cache_path() which differs on Windows vs Unix. The tool description should note: 'This tool uses platform-specific cache paths (Linux/macOS: ~/.cache/uv; Windows: %LOCALAPPDATA%/uv/cache). Ensure your system has adequate disk space in the cache directory.'