Loading ToolBench
KRU is a local credential relay unit for AI agents. It manages a secure vault of credentials and provides MCP tools for agents to access credentials, execute terminal commands, SSH operations, and HTTP requests.
KRU is a Tauri-based credential relay unit with 10 tools. However, the tool definitions are extracted only from smoke-cli.mjs test file, not from actual MCP server code visible in the repository. The source code shows Cargo.toml (Rust dependencies) and renderer/app.js (Tauri UI), but no src-tauri/src/main.rs or lib.rs with explicit MCP tool registration and schemas. Tools appear to be inferred from test smoke assertions rather than declared in the actual server implementation. This violates the 'score only what you can verify' principle. Descriptions exist but are minimal (10-80 chars, mostly under 100). Input schemas are present and properly typed with required fields identified, but lack minLength, maxLength, pattern, or enum constraints. No parameter descriptions. No documented output schemas. No error handling guidance visible. Security concern: credential_fill, ssh_run, ssh_upload, ssh_download, and http_send all handle sensitive operations but lack explicit error recovery patterns or permission gates in visible code.
Fill credentials into focused browser field through paired extension
Send HTTP requests with credentials from vault
Search and list vault items with optional filtering
Download files via SFTP using stored SSH credentials
Execute commands over SSH using stored SSH credentials
Upload files via SFTP using stored SSH credentials
Read output from an active terminal session
Tool definitions are inferred from test file (smoke-cli.mjs) rather than visible in actual MCP server implementation (src-tauri/src/main.rs or lib.rs). Cannot verify schemas, descriptions, or error handling are actually implemented in the server.
All tool descriptions are under 100 characters and lack actionable context. They do not explain WHEN to use each tool or what dependencies exist (e.g., terminal_write requires a sessionId from terminal_start, but no discovery guidance provided).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2025-06-18+ | v2 |
Start a new interactive terminal session
Stop and close an active terminal session
Write input to an active terminal session
Input schemas lack parameter descriptions. E.g., terminal_start accepts 'shell' but does not document which shells are valid (bash, sh, zsh, pwsh?), required format, or defaults. LLMs cannot reason about valid inputs.
No documented output schemas. Tools like items_search, ssh_run, and http_send return unspecified results. LLMs cannot plan downstream tool calls without knowing what fields are available.
Credentials and sensitive operations (credential_fill, ssh_*, http_send) lack error handling guidance. No documentation of what happens on auth failure, permission denied, network timeout, or invalid credentials. No recovery paths defined.
No permission gates or scope declarations visible. Credential_fill, ssh_run, ssh_upload, ssh_download, and http_send all invoke sensitive operations. No evidence of permission checks, audit logging, or scope validation in visible code.
Terminal tools (terminal_start, terminal_write, terminal_read, terminal_stop) lack idempotency guarantees. If an agent retries terminal_write with the same input, is the command executed twice? This is unspecified and unsafe for stateful shell interactions.
http_send accepts arbitrary headers and body but does not document how credentials from vault are merged into requests. Is Authorization header overwritten or preserved if the agent provides it? Ambiguous behavior.
items_search has empty input schema (no properties defined). Cannot search by name, type, or tags. Unclear if this returns all items or requires a filter that is not documented.
No retry, confirmation, or dry-run patterns for destructive operations. ssh_upload and ssh_download move files on remote systems without explicit confirmation or rollback support.