Loading ToolBench
An intelligent, AI-friendly directory visualization tool with MCP integration for project context gathering, code analysis, file discovery, and Google Drive/Gmail synchronization
The Smart Tree MCP server defines 21 tools with mixed quality. Core tools (st_overview, st_find, st_search, st_analyze) have input schemas and basic descriptions, but descriptions are hyperbolic/marketing-focused rather than LLM-optimized. Many tool descriptions use emojis and marketese ('DESTROYS Glob!', 'QUANTUM GREP', '973x FASTER') instead of precise, actionable statements. Several tools (st_edit, drive_search) lack visible input schemas entirely. Parameter descriptions are sparse or missing (e.g., st_edit has no input schema visible). Google Drive/Gmail tools expose credential parameters (client_id, client_secret, key_path) which violates secret-injection pattern. Composition is poor: st_overview, st_find, st_search, and st_analyze overlap significantly without clear differentiation. Error handling and recovery guidance are absent from all tool descriptions.
Download a file from Google Drive to local filesystem
List files in a Google Drive folder
Search for files in Google Drive
Start or run bidirectional sync between local directory and Google Drive folder
Show current sync status for Drive folder mappings
Upload a local file to Google Drive
Search for context about current project in AI tool directories. Gathers contexts from AI tools with optional temporal analysis, relevance filtering, and multiple output formats (json, m8, summary, temporal, partnership).
st_edit tool has NO visible input schema. Only a brief description 'AST SURGEON - Code editing by INTENT not DIFF' is provided. No parameters, parameter types, or constraints documented.
drive_search tool lacks input schema entirely. Description is missing details about parameters, search behavior, and expected output.
Credential parameters exposed in tool definitions (google_auth_login accepts client_id, client_secret, key_path; gmail_backup accepts drive_folder_id). Credentials must never appear as tool parameters per secret-injection pattern. Use server-side secret injection via environment variables or secure vault.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-04-07 | F | 39 | - | v1 |
Archive emails (remove from INBOX label) in Gmail
Backup emails from Gmail to Google Drive as .eml files
Check the status of ongoing Gmail backup operations
List recent emails from Gmail inbox
Search emails in Gmail
Start OAuth2 or service account authentication with Google services
Revoke and clear stored Google credentials
Check authentication status for Google services (Gmail, Drive)
📊 DEEP INSIGHTS - Analysis that makes other tools look primitive! REPLACES: Multiple Read + stat + du + git status calls. Provides statistics, semantic analysis, git status, size breakdown, and quantum-semantic modes.
✨ AST SURGEON - Code editing by INTENT not DIFF. Uses tree-sitter AST for precise code transformations and refactoring.
🔍 TURBO FIND - Semantic file discovery that DESTROYS Glob! REPLACES: Glob + find + ls + Read for discovery. Understands file types semantically (tests, config, documentation, code) without patterns.
⚡ INSTANT PROJECT SCAN - 973x FASTER than Read/Glob combo! REPLACES: Read + Glob + ls + find. Returns project overview at specified depth with automatic git context inclusion and compression.
🔥 QUANTUM GREP - Content search that makes grep obsolete! REPLACES: Grep + ripgrep + ag + Read for searching. Returns matching lines WITH content, line numbers, and context.
Analyze emails for warm storage suggestions based on relevance scoring
Tool descriptions use marketing hyperbole and emojis ('DESTROYS Glob!', 'QUANTUM GREP', '973x FASTER') instead of precise, action-oriented descriptions. LLMs cannot reliably parse marketing claims. Descriptions should follow format: 'Searches for TEXT in files matching CRITERIA. Returns matches with line numbers and optional context. Accepts regex patterns.'
Semantic overlap between st_overview, st_find, st_search, and st_analyze. All four tools can discover and analyze files. Tool names do not clearly distinguish when to use each. LLMs will struggle to choose between them. Consider consolidating or explicitly documenting the use cases: st_overview (structure), st_find (discovery by type), st_search (content search), st_analyze (metrics/git status).
No error handling or recovery guidance in any tool description. Tools do not indicate what errors might occur, whether they are retryable, or how to recover. Example: 'Returns error if path does not exist or is not readable. Ensure the path exists and the process has read permissions.' See pattern:recovery-guide.
Mutually exclusive parameters not documented. drive_sync has both 'folder_id' and 'drive_folder_id' which appear to be aliases. gather_project_context has many optional filters (project_identifiers, search_dirs, custom_dirs). Descriptions do not explain when each parameter is required vs optional, or how they interact.
Output schemas not documented for any tool. LLMs cannot plan downstream calls or extract the right data if they do not know what fields the tool returns. Example for st_overview: 'Returns {structure: string, git_status: object, size_breakdown: object, compressed: boolean}.'
Parameter 'default' and 'description' fields present but many lack clear type constraints or value ranges. Example: st_overview.depth (default=3) has no min/max. st_analyze.mode has an enum but no explanation of what each mode returns or when to use it. gather_project_context.min_relevance is a number with no 0.0-1.0 constraint stated in description.
Tool descriptions lack dependency hints and prerequisites. Example: gather_project_context assumes knowledge of 'AI tool directories' but does not explain where they are or how to find them. st_edit references 'tree-sitter AST' without explaining prerequisites or limitations.
Destructive operations (drive_upload, drive_download, drive_sync, gmail_archive, gmail_backup, gmail_archive) do not document dry-run, confirmation, or rollback options. LLMs could accidentally delete or overwrite files. Pattern:confirmation-request suggests adding dry_run flags (gmail_archive has one, but others do not).
Parameters accept only internal IDs in many cases without documented lookup tools. Example: drive_list, drive_download, drive_sync accept 'folder_id' and 'file_id' but do not provide a way for LLMs to look up files/folders by name. Pattern:natural-identifiers suggests accepting human-friendly names (file_name, folder_name) as alternatives.