Loading ToolBench
A simple MCP server built with Embabel for local file operations (CRUD). Exposes filesystem capabilities to AI agents via the Model Context Protocol using SSE
This server has severe structural and documentation deficiencies. While it uses HTTP transport (positive), the tool definitions are incomplete and poorly documented. All four tools (createFile, readFile, editFile, deleteFile) share a critical schema flaw: the 'fileContent' parameter appears in the input schema for READ operations where it makes no sense semantically. Descriptions are present but minimal (10-20 chars each), providing almost no guidance on WHEN to use each tool or what the consequences are. Parameters lack descriptions entirely, the schema shows only type declarations with no explanatory text. No output schema is documented. Error handling is absent from the visible code. The tools operate on filesystem paths without visible input validation or sanitization, creating path traversal risks. This server would not pass a code review for production use.
Create a new file with specific content.
Delete a specific file.
Edit/Overwrite an existing file.
Read the contents of a file.
CRITICAL: Malformed input schema across all tools. The 'fileContent' parameter appears in the read operation (readFile) where it should not exist semantically. This indicates the schema was copy-pasted without validation. LLMs will be confused about when to provide content vs. when to expect it in the response.
CRITICAL: No parameter descriptions provided. The FileOperationRequest DTO uses @McpToolParam annotation with description attributes, but the descriptions are trivial ('File Name', 'File Content'). These do not explain the expected format, constraints, or what values are valid. Parameter named 'fileContent' is ambiguous, is it the literal file bytes, a base64 string, or JSON? LLMs cannot infer this.
CRITICAL: No output schema documented. The code returns FileMetadata objects (visible in dto/FileMetadata.java), but there is no visible documentation of what fields agents should expect in the response. LLMs cannot plan downstream operations without knowing the response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
CRITICAL: Inadequate tool descriptions. All four tool descriptions are 10-20 characters ('Create a new file with specific content.' is 43 chars but provides minimal actionable guidance). Descriptions do not answer: What are the side effects? When should this be called vs. similar tools? What happens on error? Are there retries?
HIGH: No input validation or sanitization visible. File paths are passed directly from LLM input to filesystem operations. There is no visible check for path traversal attacks (e.g., '../../../etc/passwd'), no canonicalization, and no whitelist of allowed directories. This is a security vulnerability when agents are untrusted or prompt-injected.
HIGH: No error recovery guidance. The FileMetadata.error() factory creates error records, but the visible error response structure does not tell agents what to do next. If deleteFile fails because the file does not exist, should the agent retry, ask the user, or treat it as success? Errors must categorize as retryable, user-fixable, or fatal (pattern:recovery-guide).
HIGH: deleteFile lacks confirmation or dry-run support. Deleting a file is irreversible. There is no visible pattern for agent confirmation or dry-run preview. This violates pattern:confirmation-request. An agent in a retry loop could delete the wrong file without safeguards.
MEDIUM: editFile semantics unclear. The description says 'Overwrite an existing file' but does not explain: Does it error if the file does not exist? Does it create the file if missing? Can you append instead of replace? Does it preserve permissions? LLMs will guess.
MEDIUM: Ambiguous parameter naming. All tools accept 'fileContent' but for readFile this is marked as optional (required=false). This is confusing, why would a read operation have a content parameter at all? The schema should differ by tool (readFile should not have fileContent; deleteFile should not have fileContent).
MEDIUM: No pagination, truncation, or file size limits documented. If an agent calls readFile on a 1GB log file, what happens? Does the server read the entire file into memory? Return it in the response? Truncate silently? This is not documented, and agents have no way to know safe limits.