A Go-based MCP server that provides tools for file operations, shell command execution, and Git operations with deterministic execution capabilities and knowledge base integration.
OpenExec provides 4 tools with explicit schemas and descriptions. Most tools have well-structured input parameters with type information and meaningful descriptions. However, there are significant gaps in output schema documentation, error handling guidance, and security considerations. Tool naming follows verb_noun convention consistently. The descriptions are adequate in length (194-char baseline met for most) but lack guidance on error recovery and upstream/downstream chaining. Critical security issue: run_shell_command and write_file are high-risk tools with minimal safeguards documented. Deployment tool lacks sufficient detail on side effects and recovery paths.
Deploys the application to a specified environment using verified knowledge records.
Read the contents of a file at the specified path. Returns the file content as text. Supports reading text files of any size. For binary files, content will be returned as base64-encoded string.
Execute a shell command and return its output. Runs the command in a subprocess with configurable timeout and working directory. Returns stdout, stderr, and exit code. Use with caution as commands run with the same permissions as the server process.
Write content to a file at the specified path. Creates the file if it doesn't exist, or overwrites it if it does. Parent directories must exist. For binary content, provide base64-encoded data with encoding set to 'binary'.
run_shell_command lacks input validation and injection-attack guidance. Description does not explain sanitization responsibilities or highlight command-injection risks when args are user-supplied.
No output schema documented for any tool. LLMs cannot plan downstream chaining or extract fields reliably when return structure is unspecified.
deploy tool description is severely under-specified (45 chars). Does not clarify what 'verified knowledge records' means, what each action does, rollback behavior, or error recovery steps.
write_file and run_shell_command are irreversible/destructive but lack confirmation-request or dry-run support. No pattern guidance for agents to preview changes before committing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Error handling descriptions are minimal. No guidance on how to recover from failures (e.g., 'File not found, use list_files to discover paths' or 'Command timeout, reduce complexity or increase timeout_ms').
run_shell_command timeout_ms parameter has max 600000 (10 min) but lacks rationale. Description should explain why 10 min is the ceiling and what happens if command exceeds it.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs cannot determine safety profile of tools without explicit metadata.
write_file 'create_directories' defaults to false, which silently fails if parent dirs don't exist. A default of true (common case) would reduce surprise failures; description should justify the conservative choice.