A secure Docker sandbox management server for AI agents with quota-based access control, billing integration, and Telegram bot interface
Agent Jail MCP has 6 tools with basic descriptions and parameter schemas, but significant quality gaps prevent production use. Tool names are clear and action-oriented (docker_health, create_sandbox, run_in_sandbox, destroy_sandbox, list_sandboxes, cleanup_expired_sandboxes). However, descriptions are minimal (10-50 chars), parameter descriptions are absent or trivial, output schemas are undocumented, and error handling is generic. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Parameters lack constraints (enums, ranges, patterns). The server exposes dangerous operations (destroy_sandbox, cleanup_expired_sandboxes) without confirmation patterns or permission gates. Error responses return raw exception strings rather than actionable guidance.
Destroy expired sandboxes.
Create a disposable Docker sandbox for AI agents. Returns sandbox_id.
Force destroy a sandbox container.
Check if Docker daemon is reachable.
List all agent-jail sandbox containers.
Run a shell command inside the sandbox container. timeout=0 uses default timeout.
Destructive operations lack confirmation or dry-run patterns. destroy_sandbox and cleanup_expired_sandboxes can permanently delete containers without agent confirmation, risking data loss.
Parameter descriptions are missing or trivial. 'image' in create_sandbox says '(optional, uses default if empty)' but does not explain what images are valid, how to discover them, or what the default is. LLMs cannot infer valid values.
Tool descriptions are too short (10-50 chars). 'Check if Docker daemon is reachable' and 'List all agent-jail sandbox containers' lack context on WHEN to call them, what they return, or how they fit into workflows. Baseline is 194 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Output schemas are undocumented. No tool specifies what fields it returns (e.g., create_sandbox returns sandbox_id, name, image, expires_at, but this is inferred from api.py, not declared in server.py). LLMs cannot plan downstream calls without knowing response structure.
Error handling returns raw exception strings ('error': str(exc)). No actionable guidance, no error classification (retryable vs fatal), no recovery hints. LLMs cannot self-correct or decide next steps.