Loading ToolBench
Exposes the machine where lrmcp is running. Provides filesystem, image, process, browser, and computer control tools. Filesystem and image tools accept direct absolute paths or paths relative to the server process. Process tools execute installed programs directly without shell parsing and return sessions for longer programs. Browser tools use the bundled Chromium extension over an authenticated loopback bridge. Computer tools operate the current interactive desktop and target open windows.
Strong foundation with 20 well-named tools, comprehensive schemas, and tool annotations present. All tools have descriptions (avg 95 chars, within baseline 34-392). Naming follows verb_noun pattern consistently (filesystem_*, browser_*, process_*, computer_*). Schemas are detailed with type definitions and parameter descriptions. However, output schemas are not documented, LLMs cannot predict return structures. Error handling guidance is absent; tools lack recovery hints. Some parameter descriptions could be more prescriptive about constraints and formats. No batch variants offered despite agents calling similar tools in loops.
Perform an action on a browser page element or page.
Close a browser tab.
Navigate a browser tab to a URL or perform navigation actions.
Open a new browser tab.
Capture a screenshot of the browser viewport or full page.
Capture a snapshot of the browser page DOM and accessibility tree.
Get the status of the browser bridge connection.
List open browser tabs.
Output schemas not documented. LLMs cannot predict return structures for any of the 20 tools, forcing them to guess at downstream field names and types. This violates the pattern:tool requirement and increases hallucination risk.
Error handling lacks recovery guidance. Tools like process_run and browser_action have no documented error cases or recovery hints (e.g., 'If timeout occurs, retry with longer timeout_seconds'). Agents cannot self-correct on failures.
process_continue parameter 'action' lacks enum constraint and description detail. The description says 'action to perform on the session' but does not list valid actions (read, write, resize, wait, terminate). LLMs will hallucinate invalid action values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Perform an action on a desktop window or UI element.
Capture the current state of a desktop window or the entire screen.
List available desktop windows and targets.
List a bounded number of files and directories below a direct machine path without following symbolic links.
Apply uniquely anchored, non-overlapping UTF-8 hunks against one expected file version and commit them atomically.
Read bounded complete UTF-8 lines from a direct machine path, starting at any one-based line.
Search bounded UTF-8 files below a direct path using literal text or a Go regular expression.
Inspect a direct path without following symbolic links; optionally calculate a regular file's SHA-256.
Atomically create or replace a complete UTF-8 text file, optionally requiring an expected SHA-256.
Return a direct PNG, JPEG, GIF, or WebP path as native MCP image content with metadata.
Read incremental output, write or close pipe stdin, resize a PTY, wait for, or terminate a process session.
Start a program directly in pipe or interactive PTY mode. Completed programs return their result; longer programs return a session ID.
browser_action 'kind' enum is extensive (11 values) but descriptions for conditional parameters (ref, screenshot_id, x, y, text, key, etc.) do not explain which are required for each kind. Agents will pass incomplete or conflicting parameters.
No batch variants offered. Agents calling filesystem_search_text or browser_action in loops will make N sequential calls instead of one batch call, wasting tokens and latency. Consider batch_filesystem_search or batch_browser_actions.