A local agent orchestrator that executes tasks on the device without external API transmission, ensuring privacy compliance
This server has severe quality gaps. The single tool 'run_local_task' has a problematic name (generic 'run' verb), minimal description (only 91 characters), and an input schema with critical issues. The implementation is not a true MCP server, it's a standalone Python class with no MCP protocol support visible in the source. The server cannot be instantiated as an MCP server without MCP SDK scaffolding (initialize, tools, call handlers). Tool descriptions and parameter handling lack LLM-optimization guidance. Error handling is completely absent, the mock implementation returns hardcoded success with no validation, error categorization, or recovery guidance.
Executes a task locally on the device without external API transmission
Tool name 'run_local_task' uses generic verb 'run' instead of action-specific verb. Per pattern:tool, names should start with clear action verbs (execute_, invoke_, process_). 'run' is ambiguous and does not convey specifics to LLMs.
Tool description is only 91 characters, below the recommended minimum of 150 chars for clarity. Description does not answer: When should the LLM call this instead of a similar tool? What exactly is returned? Does it modify state? Required for proper tool selection.
'allowed_permissions' parameter has array items with type 'string' but no enum constraint or description of valid permission values. LLMs will hallucinate permission strings. No guidance on format (read_file, write_file, execute, etc.) or how permissions are validated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 26 | 2026-07-28+ | v2 |
No output schema documented. The mock implementation returns {'execution_result': string, 'privacy_compliance': boolean}, but this is not declared in the tool definition. LLMs cannot plan downstream operations without knowing return structure.
No error handling. The implementation is a mock that always returns success. No validation of local_prompt or allowed_permissions. No error recovery guidance. LLMs have no way to know what went wrong or what to retry.
Not a true MCP server. The source contains only a Python client class with no MCP server implementation visible. No mcp.Server initialization, no tool registration handlers, no MCP protocol transport (STDIO, HTTP, SSE). This cannot function as an MCP server without MCP SDK scaffolding.
Security risk: 'allowed_permissions' parameter suggests permission validation, but no actual permission checks are visible in the mock implementation. Destructive operations (write_file, delete, etc.) need gate checks per pattern:permission-gate.
Parameter 'local_prompt' has a generic description ('The task or instruction to execute locally') with no format guidance, length limits, or examples of valid inputs. Does it support shell commands, natural language, scripts? Ambiguous for LLMs.