Loading ToolBench
Unofficial MCP server for analyzing Lovable-generated projects with Claude Desktop. Community-built tool for enhanced development workflow. Not affiliated with Lovable.
This MCP server provides 10 read-only project analysis tools for Lovable-generated React/TypeScript projects. While tool names follow verb_noun conventions reasonably well, the implementation has critical gaps: (1) Most tools have empty input schemas (no parameters) despite accepting no arguments, creating ambiguity about extensibility. (2) Descriptions are present but generic and lack LLM-optimized clarity about WHEN to call each tool vs. alternatives. (3) Output schemas are completely undocumented, the source shows tools return JSON.stringify() of objects, but the schema structure is invisible to consumers. (4) No error recovery guidance, error responses are bare error.message strings. (5) Parameter descriptions are entirely absent for tools that do accept parameters (e.g., get_file_content, search_files). The server reads code files, extracts metadata, and performs analysis, all read-only operations with no state mutation, which is a security plus. However, the definition quality falls short of production grade due to missing schemas, sparse documentation, and no guidance for parameter-driven tools.
Analyzes database schema information from Supabase or other database configurations in the project. Extracts table definitions, relationships, and column metadata.
Analyzes project dependencies from package.json and categorizes them into: react, ui, state, routing, styling, database, build, testing, utilities, and other. Provides framework detection for React, Next, Vite, Tailwind, Supabase, and TypeScript.
Analyzes the project structure, extracts package.json metadata, counts file types (tsx, jsx, ts, js), and detects frameworks and libraries used (React, TypeScript, Vite, Next.js, Tailwind, Supabase).
Retrieves and analyzes React/JSX components in the project. Detects component patterns including default exports, named exports, props usage, state management (useState), and hooks (useEffect). Returns analysis for up to 20 component files.
Retrieves environment configuration information from .env files and environment variable patterns in the project. Redacts sensitive values for security.
Output schemas completely undocumented. Tools return JSON via JSON.stringify(object), but the actual field structure, types, and nesting are invisible to MCP consumers. An LLM cannot know what fields to expect or plan downstream operations.
Parameter descriptions missing for tools that accept arguments. get_file_content has a 'path' parameter with no description explaining format (relative vs absolute, required prefixes, allowed extensions). search_files has 'query' and 'pattern' with no guidance. LLMs cannot infer parameter intent from names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Retrieves the content of a specific file from the project. Accepts a relative file path.
Analyzes routing structure by searching for routing configuration files (router, routes, App, main, index files). Detects route paths using regex patterns and identifies protected/private routes based on auth keywords.
Analyzes Tailwind CSS usage in the project by scanning component files for Tailwind class names and utility patterns.
Lists files in the project matching optional patterns. Can filter by file extensions and exclude directories like node_modules, dist, and build.
Searches for files containing specific text patterns or regular expressions across the project.
Tool descriptions are generic and lack differentiation. get_components, get_routing_structure, and analyze_dependencies all return 'extracted' or 'analyzed' metadata but descriptions do not explain WHEN to call each vs. the others, or what the user should do with the results. Descriptions should guide LLM tool selection.
Input schemas for parameter-accepting tools are incomplete. get_file_content and list_files show properties but no required array, type definitions are minimal (only 'type': 'string' shown), and no constraints (regex, min/max length, enum) are declared. Parameters lack descriptions entirely.
No error recovery guidance. Error responses return bare error.message strings (e.g., 'Error in analyzeProject: <message>'). Errors do not categorize as retryable, user-fixable, or fatal, nor do they suggest recovery actions. An LLM encountering 'No package.json found' cannot infer whether to retry or adjust its approach.
Result limits not enforced or documented. get_components slices to 20, but description does not state 'Returns up to 20 components; use list_files with pattern to get more.' get_routing_structure slices to 20 routes; analyze_dependencies does not slice at all. Large unbounded results risk blowing context windows.
No pagination or cursor support for result sets. list_files and search_files accept optional parameters but return unstructured arrays with no next_cursor, total_count, or offset guidance. Large projects could return hundreds of files, exhausting context.
Parameter constraints not documented or validated. get_file_content accepts a 'path' parameter but does not document: Is it relative to project root? Can paths escape via '../../../'? What extensions are allowed? If LLMs are not told the constraints, they will pass invalid paths.
Tool chaining information missing. If a tool returns file paths (e.g., search_files returns {path, match}), but get_file_content expects a 'path' parameter, the MCP definition should document that search_files.path feeds directly into get_file_content.path. Current definitions lack this guidance.
Missing tool annotations (readOnlyHint, idempotentHint). All 10 tools are read-only and idempotent, but these are not declared in the tool definitions. LLMs cannot automatically infer safety properties and may hesitate to call analysis tools repeatedly.