Enhanced macOS finder using MCP with intelligent file indexing and retrieval
Better Finder MCP has clear tool naming following verb-noun convention (search_files, index_files, get_file_content, get_stats, configure_paths). All 5 tools are explicitly defined with input schemas visible in mcp_server.py. However, tool descriptions are generic and lack critical context for LLM decision-making. Parameter descriptions exist but are minimal, most lack validation guidance, ranges, or format specifications. No output schemas are documented, making it impossible for LLMs to plan chained operations. Error handling and recovery guidance are absent. Tool composition is reasonable (each handles one concern), but lacks the detail required for production-grade agent interaction.
Add or remove paths from scanning configuration
Get the content of a specific file
Get current indexing statistics
Index files in the specified directory or perform full reindex
Search for files using intelligent semantic and filename matching
No output schemas documented. LLMs cannot infer what fields search_files returns, preventing proper chaining to downstream operations. Critical for agent planning.
Tool descriptions lack context for LLM decision-making. 'Search for files using intelligent semantic and filename matching' doesn't explain WHEN to call it vs browsing, what the output format is, or prerequisites (indexer initialized?). Descriptions should be 50-200 chars and answer: what, when, what returns.
Parameters lack validation constraints and format guidance. 'query' in search_files has no hint on length, character restrictions, or expected format. 'max_results' has no min/max bounds. 'path' in index_files and configure_paths has no validation guidance for directory vs file.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
index_files and configure_paths are write operations but lack dry-run or confirmation mechanism. An LLM could trigger a full reindex or delete paths unintentionally. Consider adding a 'confirm' parameter or dry-run preview.
No error handling or recovery guidance visible in code. Tools return success/failure but lack actionable error messages. If search_files returns empty, LLM has no hint to index_files first. If configure_paths fails, no guidance on why.
get_file_content accepts 'max_length' parameter (default 5000) but no description explains truncation behavior, what happens if file is larger, or whether response includes an 'is_truncated' flag for chaining decisions.
configure_paths 'action' enum includes 'list' but the description doesn't clarify whether 'path' parameter is ignored/required for 'list'. Undocumented parameter dependencies invite misuse.
search_files 'file_type' enum has 'any' option but no explanation of what it means or what default behavior is if omitted. Ambiguous enums cause LLM confusion.