Loading ToolBench
poke-gate exposes 9 tools with complete input schemas and descriptions. Naming follows verb_noun convention (run_command, read_file, write_file, list_directory, system_info, read_image, run_agent, take_screenshot, network_speed). However, descriptions lack depth, most are 1 - 2 sentences without guidance on when to use each tool, prerequisites, or error recovery. Parameter descriptions are minimal (e.g., 'Working directory (optional, defaults to home)' for cwd). Output schemas are not documented. Error handling is present but generic. Security-sensitive tools (run_command, write_file, take_screenshot) implement approval workflows, but descriptions do not explain the approval flow or AWAITING_APPROVAL response format. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels.
List files and directories at a given path on the user's machine.
Run a built-in internet speed test and return download/upload Mbps. Uses Cloudflare speed endpoints internally without requiring shell pipelines.
Read the contents of a file on the user's machine.
Read an image or binary file and return it as base64-encoded data. Supports png, jpg, jpeg, gif, webp, pdf, and any other binary file. Returns the base64 string and MIME type.
Run a Poke Gate agent by name. Agents are scheduled scripts in ~/.config/poke-gate/agents/. Use this to manually trigger an agent — it will execute and send its results to you.
Execute a shell command on the user's machine and return stdout, stderr, and exit code. Use this to run any CLI command (ls, cat, git, brew, python, curl, etc.). Commands run in a shell with a 30-second timeout.
Output schemas not documented. Tools return results but LLMs cannot plan downstream calls without knowing response structure (e.g., what fields does run_command return? Is it {stdout, stderr, exit_code} or {output, error, status}?). This forces agents to guess and wastes tokens on trial-and-error.
Approval workflow (approval_token, approve, remember_in_session, remember_all_risky) is undocumented. Descriptions do not explain what AWAITING_APPROVAL response looks like, how to obtain approval_token, or when the LLM should set approve=true. This breaks the approval flow for agents.
No tool annotations despite clear risk levels. run_command and run_agent are marked IRREVERSIBLE; write_file and take_screenshot are WRITE; others are READ_ONLY. MCP spec supports destructiveHint, readOnlyHint, and idempotentHint annotations, these should be added to help agents reason about safety.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
Get system information: OS, hostname, architecture, uptime, memory, and home directory.
Take a screenshot of the user's screen and save it to a file. Returns the file path. Requires screen recording permission on macOS.
Write content to a file on the user's machine. Creates the file if it doesn't exist, overwrites if it does.
Parameter descriptions lack format/constraint guidance. E.g., 'cwd' says 'defaults to home' but does not specify absolute vs relative paths, symlink handling, or path traversal guards. 'command' does not document timeout (30s), shell type (bash/sh), or environment variables available.
Error handling is generic. Code shows permission checks and command validation, but tool descriptions do not explain error responses. E.g., what does run_command return on timeout? On permission denial? On invalid shell syntax? Agents need actionable error guidance.