Loading ToolBench
MCP server exposing local StashBase projects to Claude Desktop and Claude CLI, providing file and project operations with semantic search capabilities
StashBase MCP Server has 11 tools with generally adequate naming and some descriptions, but significant gaps in schema completeness, parameter descriptions, and error handling guidance. Tool names follow verb-noun convention well (list_*, read_*, write_*, search_*, delete_*, move_*, create_*), which is positive. However, parameter schemas are either missing or incomplete for most tools, descriptions vary widely in depth and actionability, and there is minimal error recovery guidance. The server targets a specialized domain (local file-based project management with semantic search), which is well-defined, but the tool interface does not fully optimize for agent composition or common user workflows.
Create a new StashBase project with a name and location.
Delete a file from the project.
Edit a file by replacing old text with new text. Supports replace-all mode and optional baseVersion for optimistic locking.
List visible files and folders within one registered project. Pass an absolute folder/subfolder path to list its immediate contents. Paths are absolute POSIX paths. Hidden app-maintained derived notes and bundle folders are not surfaced.
Return StashBase project locations as `{folder_home, folders}`, where `folder_home` is the default new-folder location and `folders` lists "Your Folders", each with an ABSOLUTE `path` (the identity the file tools and search_project use), a display `name`, and the embedder provider. Folders can live anywhere on disk. Sandboxed runtime filesystem tools may not be able to see these host paths; the StashBase file tools operate on them.
Move or rename a file to a new path. Optionally cascade the move to related files.
Multiple write/destructive operations (write_file, edit_file, delete_file, move_file) lack error recovery guidance and dry-run capability. Descriptions do not explain what happens on failure, what to do if optimistic locking fails, or how to recover from partial failures.
Parameter descriptions are sparse or missing. read_file accepts 'offset' and 'limit' with minimal guidance on units (lines? bytes?). edit_file's 'replace_all' boolean has no description. search_project's 'types' parameter description is cut off ('Optional array of file type filters' but no examples or valid values). Many parameters lack type/range constraints in descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Read a file from StashBase by absolute path (for example `/Users/me/not
Reindex the project or an optional folder within it for semantic search.
Search project files with optional filtering by type, path prefix, and search mode (keyword or semantic). Returns hits with file names, matched lines, and line numbers.
Suggest edits for a file within an optional folder scope. Returns a list of suggested edit operations.
Write content to a file in StashBase. Creates the file if it does not exist, or replaces it entirely if baseVersion matches.
suggest_edits tool naming is vague. The name suggests it returns suggestions, but the description ('Suggest edits for a file within an optional folder scope. Returns a list of suggested edit operations.') does not explain what logic generates suggestions, what input 'content' means (new content vs. context?), or when to prefer it over direct edit_file. This creates ambiguity for LLM tool selection.
Output schemas are not documented in tool descriptions. Tools return results, but the response structure (what fields, types, pagination) is not visible in the MCP tool registration. Agents cannot plan downstream calls without knowing what fields the response contains. For example, does list_directory return 'files' and 'folders' separately? Does search_project return 'file_path' or 'path'? Does it include match context?
No error handling guidance. None of the tool descriptions indicate what errors can occur, what the LLM should do if they happen, or how to recover. For example, write_file mentions 'baseVersion' for optimistic locking but does not describe the error case when versions conflict or how to retry.
read_file description is truncated in the provided schema ('Read a file from StashBase by absolute path (for example `/Users/me/not'). The full description is cut off, making it unclear what the tool returns or how 'offset' and 'limit' interact with file size.
search_project's 'top_k' parameter defaults to 8 with a max of 25, but the description does not explain why semantic search returns limited results or how pagination works when more results exist. If top_k=8 is not the full result set, there should be a next_cursor or pagination token to fetch additional results.
reindex is marked as READ_ONLY but its actual impact (rebuilding semantic indices) is a heavy write operation. The description does not clarify what 'reindex' does, how long it takes, whether the folder is locked during reindex, or what happens if the agent calls it multiple times in parallel.
No parameter validation constraints visible. For example, create_project accepts 'name' and 'location' as free-form strings with no guidance on naming rules, length limits, or filesystem restrictions. list_directory accepts 'path' with no validation that it is an absolute path within a registered project. search_project's 'query' is required but has no length limit or format constraints.