Loading ToolBench
A gateway skill for monitoring mobile device coding assistant agent task status and terminal output in real-time
This server has a single tool with a verb-based name that follows basic conventions. However, critical gaps in schema documentation, parameter descriptions, output schema specification, and error handling severely limit its usability. The tool definition is visible in client.py but lacks the rigor expected of production-grade MCP servers. The implementation is a mock that returns hardcoded data rather than a real integration.
Get the current status of an active coding assistant agent task on a mobile device, including task execution state, progress percentage, and live terminal summary
No documented output schema. The tool returns a dict with fields 'task_status', 'progress_percentage', and 'live_terminal_summary', but no schema is provided to the MCP server. LLMs cannot predict what fields to expect or plan downstream tool calls.
Parameters lack detailed descriptions. 'active_agent_task_id' and 'mobile_device_id' have only basic descriptions ('The unique identifier of...'). No guidance on format, valid value constraints, or examples of valid input. Does task_id follow a pattern like 'task-XXXX'? Is it an integer or UUID? LLM must guess.
Tool description is minimal (53 characters). While it states what the tool does, it does not explain when to use it vs. alternatives, prerequisites, or dependencies. No guidance on whether calling this tool is safe to retry or what 'EXECUTING_REFACTORING' status means.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
No error handling or recovery guidance. The mock implementation returns hardcoded success. Real implementation provides no error codes, no guidance for invalid task_id or device_id, no explanation of failure modes. An LLM encountering an error (task not found, device offline, permission denied) has no recovery path.
No input validation or constraints documented. Parameters are free-form strings with no length limits, regex patterns, or enum constraints. The tool can be called with arbitrary input and the LLM has no way to know what constitutes valid input.
Output fields not self-documenting. 'task_status' field returns values like 'EXECUTING_REFACTORING' but no enum or documentation of valid status values. LLM cannot reason about status transitions or when a task is complete. Is 'EXECUTING_REFACTORING' the only possible status or one of many?
Mock implementation not production-ready. The code in client.py returns hardcoded status and ignores input parameters. This is placeholder code, not a functional MCP server integration. Real implementation details, backend connectivity, and actual device communication are absent.