Loading ToolBench
Forkscout AI agent — Telegram + LLM + MCP + Tools. A multi-channel AI agent with MCP tool integration, supporting Telegram, WhatsApp, Discord, Slack, Matrix, LINE, and CLI interfaces.
Forkscout provides 10 tools with mostly complete schemas and descriptions. Naming follows verb_noun conventions (clipboard_tools, edit_file_tools, grep_search). Descriptions are detailed and include WHEN/NOT TO USE guidance, exceeding the 194-char baseline average. However, several tools lack output schema documentation, parameter descriptions are sometimes generic, and error handling lacks recovery guidance. Tool composition is sound (each does one thing), but some tools expose implementation details (e.g., /tmp/forkscout-http/ paths) that should be abstracted. Security is reasonable (secrets via vault), but no explicit permission gates or audit trail declarations.
Execute any on-demand tool from .agents/tools/ by name. Use AFTER find_tools() returns a match. Pass the exact tool name returned by find_tools and a JSON object of parameters. Example: call_tool('compress_text_tools', { text: '...', method: 'summarize' }). Do NOT use this for bootstrap tools already in your active list — call those directly.
Read from or write to the system clipboard. Use action='read' to get the current clipboard contents. Use action='write' with text= to copy text to the clipboard.
Edit files by replacing exact string matches — no need to read and rewrite the whole file. Pass an array of edits: each with path, oldString (exact text to find), and newString (replacement). CRITICAL RULES: (1) Always read the file first so you know the exact content. (2) oldString must appear EXACTLY ONCE — include at least 3 lines of surrounding context to ensure uniqueness. (3) Match whitespace exactly — tabs vs spaces matter. (4) Never include line numbers in oldString. Use replaceAll:true to rename a variable, type, or import across the entire file. WHEN NOT TO USE: full file rewrites — use write_file_tools; creating new files — use write_file_tools. Batch edits: put all changes to the same file in one call rather than separate calls. Example: {path: 'src/config.ts', oldString: ' timeout: 30,\n retries: 3', newString: ' timeout: 60,\n retries: 5'}
Find files by glob pattern across the workspace. Returns matching paths sorted by modification time. Supports patterns like 'src/tools/*.ts', '**/*.json', 'src/**/README.md'. WHEN TO USE: finding files by name, extension, or path prefix; checking if a file exists; discovering all files of a type (e.g. all .ts files under channels/). WHEN NOT TO USE: searching for text inside files — use grep_search_tools. Listing one directory — use list_dir_tools (simpler). Always batch: pass multiple patterns in one call. Example: patterns: ['src/channels/**/*.ts', '**/*.config.json'] finds all channel TS files + all config files.
Output schemas not documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing response structure (e.g., what fields does grep_search return? Is it {file, line, match} or {path, lineNumber, matchedText}?).
Error handling lacks recovery guidance. Tools return errors (e.g., 'file not found', 'permission denied') but do not suggest next steps. Per pattern:recovery-guide, errors should tell the LLM what to do: 'File not found. Check the path or use file_search_tools to locate it.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Search for on-demand tools in .agents/tools/ by keyword or exact tool name. WHEN TO USE: (1) any time you need a capability not in your bootstrap tools; (2) when a specific tool (e.g. validate_and_restart, web_browser_tools, telegram_message_tools, git_operations_tools, sqlite_tools, etc.) is not in your active tool list — search here before concluding it doesn't exist. 30+ extended tools are available: browser, git, SQLite, regex, PDF, image analysis, workers, cron, network scan, run_code, validate_and_restart, and more. Returns tool name, full description, and parameter names — enough to call the tool immediately after. WHEN NOT TO USE: for bootstrap tools already loaded (read_file_tools, edit_file_tools, run_shell_command_tools, web_search_tools, find_tools itself, etc.). Do NOT use file_search_tools or project_sourcemap_tools to look for tools — use this. Example queries: 'validate_and_restart', 'web browser', 'git commit', 'telegram message', 'sqlite database', 'parallel workers', 'schedule cron job'.
Run TypeScript typecheck (bun run typecheck → tsc --noEmit) and return structured errors with file, line, column, error code, and message. WHEN TO USE: after any code change to verify nothing is broken; before committing or restarting; when you suspect a type error but aren't sure which file. WHEN NOT TO USE: runtime errors (not type errors) — use run_shell_command_tools to run the actual code. Returns: error_count, list of {file, line, col, code, message} objects. If clean, returns { error_count: 0, message: 'No type errors'. }. Example: {} — run with defaults to check the whole project.
Run git commands for version control: status, commit, push, pull, log, branch, diff, stash, fetch. WHEN TO USE: checking what changed (status, diff); committing code after a task (commit + push); reviewing recent history (log); creating/deleting branches; stashing/restoring in-progress work. WHEN NOT TO USE: arbitrary shell operations — use run_shell_command_tools; typecheck before commit — use get_errors first. Pass 'args' for extra flags (e.g. args: ['--oneline', '-10'] for short log). Examples: commit: {command: 'commit', message: 'feat: add cron job support'} | push: {command: 'push', remote: 'origin', branch: 'main'} | recent log: {command: 'log', args: ['--oneline', '-10']}
Search for text patterns or regexes across the codebase. Returns file paths, line numbers, and matched lines. WHEN TO USE: finding where a function, class, constant, or import is used; locating where a config key or error message appears; finding all usages before renaming something; checking if a pattern exists without reading entire files. WHEN NOT TO USE: finding files by name pattern — use file_search_tools; reading full file content — use read_file_tools. Use 'include' to restrict to a file type: '*.ts', 'src/channels/**'. Supports full regex: e.g. 'export const \w+_tools' to find all tool exports. Example: {pattern: 'buildIdentity', include: '*.ts'} finds all usages of buildIdentity in TypeScript files.
Make HTTP requests (GET, POST, PUT, PATCH, DELETE) to any URL with custom headers and body. WHEN TO USE: calling external APIs (REST, webhooks, health checks); sending data to a service; checking if a URL is reachable. WHEN NOT TO USE: browsing or scraping web pages with JavaScript — use web_browser_tools (full Playwright); simple web content fetching without interactivity — try this first, fall back to web_browser_tools if JS required. Large responses (>10KB) are automatically saved to /tmp/forkscout-http/ and the path is returned — use read_file_tools to read them. Set headers as a plain object: {'Content-Type': 'application/json', 'Authorization': 'Bearer {{secret:api_token}}'}. Example: {url: 'https://api.example.com/users', method: 'POST', body: JSON.stringify({name: 'Alice'}), headers: {'Content-Type': 'application/json'}}
List files and subdirectories in one or more directories. Returns entry names — directories end with '/'. WHEN TO USE: exploring module structure, confirming a folder exists, seeing what files are present. WHEN NOT TO USE: searching files by name pattern across the project — use file_search_tools (glob) instead; reading file content — use read_file_tools; counting deeply nested files — use file_search_tools. Always batch: pass multiple paths in one call instead of calling once per folder. Example: paths: ['src/tools', 'src/channels', '.agents/tools'] lists all three at once.
http_request_tools exposes implementation detail (/tmp/forkscout-http/) in description. Per pattern:response-shaper, strip internal paths and return only what the agent needs. Abstraction should hide file system details.
call_tool parameter 'input' lacks type specificity. Described as 'JSON object' but no schema for what keys/values are valid. LLMs cannot validate before calling. Should reference find_tools output or provide a schema template.
No tool declares permissions or scopes (e.g., 'read:filesystem', 'write:git'). Per pattern:scope-declaration, tools should state what authority they require for audit and least-privilege configuration.