Loading ToolBench
FastMCP server for read-only filesystem access with configurable root paths and file type filters
mcp-filesystem-readonly presents a focused, read-only filesystem tool suite with clear naming and reasonable parameter documentation. All 4 tools have descriptions and proper schemas. However, descriptions lack LLM optimization depth (most are 50-150 chars but could be more prescriptive about WHEN to use each), parameter descriptions are present but sparse, and output schemas lack explicit documentation in the code. Error handling is implemented in the tools (path validation, filter validation) but recovery guidance in descriptions is minimal. Naming is verb-forward and clear (list_*, health_check). The server follows basic patterns well but misses several production-grade refinements: no tool annotations (readonly hints would reinforce the security model), no batch operations or pagination guidance, and no composition hints for multi-tool workflows.
Return a simple health status indicating the server is running.
List the contents of a directory within the configured roots.
Return all available inclusion filters for use with list_folder. Filters define which file types and folders are included in directory listings. Call this first to discover valid filter names, then pass one to list_folder.
Return the configured root paths available for filesystem listing.
Tool descriptions lack LLM-optimized guidance on WHEN and WHY to call each tool in a sequence. For example, list_folder does not explicitly state 'Call list_inclusion_filters() first to discover valid filter names', it mentions it in passing but should lead with this as a dependency hint.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Since this is a read-only server, all tools should declare readOnlyHint=true to help agents and frontends understand the safety profile without parsing descriptions.
Output schemas are not documented in the tool descriptions or in the source code visible to the LLM. While the Python code shows return types (dict[str, Any], list[dict[str, Any]]), the MCP tool registration (in server.py snippet is truncated) may not carry explicit output schema documentation. LLMs need to see field names and types (e.g., 'returns a list of dicts with keys: name (str), size_mb (float|null), is_folder (bool)').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 62 | - | v1 |
Parameter descriptions are minimal. 'path' in list_folder says 'Absolute path of the directory to list. Must be within one of the configured roots.' but does not explain what happens if a relative path is passed, the exact error message format, or examples of valid root-relative paths. Similarly, 'inclusion_filter_name' mentions calling list_inclusion_filters but does not state 'Must be one of the filter names returned by that tool.'
Error messages in list_folder are detailed (e.g., 'Path is outside all configured roots', 'Unknown inclusion filter X. Valid filter names: Y, Z') but tool descriptions do not document what errors can occur or guide recovery. An LLM seeing a ValueError for an invalid filter must infer it should call list_inclusion_filters; this should be explicit in the description.
No pagination or result limiting guidance. list_folder may return thousands of entries on large directories, potentially exhausting context. The description should mention any implicit limit or recommend querying subdirectories if results are large.