Loading ToolBench
A secure MCP server that exposes explicitly configured Linux directories as controlled workdirs to AI agents, read-only by default with opt-in per-workdir file mutation.
ServerFS MCP demonstrates solid tool design with comprehensive schemas, clear naming conventions, and good parameter documentation. All 24 tools have explicit descriptions and typed input schemas. Tool names follow verb_noun patterns (list_*, read_*, create_*, delete_*, submit_*, etc.). However, output schemas are not documented in the visible code, descriptions vary in quality (some are excellent, others generic), and error handling guidance is minimal. Agent-related tools (submit_agent_task, respond_agent_approval) include ToolAnnotations which is excellent. The server shows production-grade structure but lacks LLM-optimized descriptions and recovery guidance.
Answer a pending Agent task question.
Cancel a running Agent task.
Create a new binary file from base64-encoded data.
Create a new directory (idempotent).
Create a new text file with specified content.
Delete an empty directory.
Delete a file with revision guard.
Output schemas not documented. Tool descriptions specify inputs but do not document return types, field names, or structure. LLMs cannot plan downstream tool calls or extract required data without knowing what fields to expect.
Error handling lacks recovery guidance. Tool descriptions do not explain what to do if a call fails (e.g., 'file not found, try list_directory first'). Agents receive errors but no actionable next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 81 | <=2025-11-25 | v2 |
Edit a text file with revision-guarded changes.
Search for files matching a pattern using ripgrep.
Get the normalized state/result or pending interaction for one Agent task.
List configured Agent runtimes and their current normalized capabilities. This is read-only and never starts or installs a provider. Runtimes not allowlisted on any ServerFS workdir are omitted.
List directory contents with optional filtering and pagination.
List all configured workdirs and their access mode (read-only or read-write).
Read cursor-paginated normalized task events; never raw provider stdout/stderr.
Read an exact byte-ranged UTF-8 chunk from a spooled Agent result.
Read a binary file as base64-encoded data with optional byte range.
Read a text file with optional line range pagination.
Replace an existing binary file with revision guard.
Respond to a pending Agent task approval request.
Search for text content in files using ripgrep.
Send a message to a running Agent task.
Get file metadata (size, permissions, timestamps, etc.) without reading content.
Submit one narrow authorized Agent objective and return a task handle. Keep the task atomic: provide only the context required for the objective, explicitly bound allowed mutations and stop conditions, and prefer existing structured project workflows over embedding unrelated shell/network/security implementation detail. This guidance reduces ambiguity and accidental scope expansion; it does not weaken or bypass provider safety checks. The call never waits for provider completion. Poll get_agent_task or read_agent_task_events. A follow-up conversation uses a NEW task with continue_from_task_id.
Upload a binary file through the optional file ingress channel.
Agent task tools lack confirmation/dry-run pattern. submit_agent_task, respond_agent_approval, and cancel_agent_task are destructive but offer no preview or confirmation step. Agents cannot verify intent before irreversible actions.
Some descriptions are generic or under-optimized for LLM selection. 'Get file metadata' and 'Delete an empty directory' lack context on when to use them vs similar tools. Descriptions should answer: What does it do? When should I call it? What does it return?
Pagination parameters (limit, offset, cursor) present in some tools but not consistently documented. list_directory has 'limit' but no mention of total count or next_cursor. Agents cannot reliably iterate large result sets.