Loading ToolBench
Model Context Protocol (MCP) Server for Advanced Haskell Code Analysis - 40+ Comprehensive Analysis Tools
This FDEP MCP server exposes 7 read-only code analysis tools with complete JSON schemas and descriptions. However, the definitions lack depth in several critical areas: parameter descriptions are minimal or absent, error handling strategies are undocumented, output schemas are not formally declared, and tool descriptions do not explain WHEN to use each tool or what downstream actions they enable. The naming follows verb_noun convention (get_*, list_*, search_*), which is correct, but parameter documentation is sparse. All tools are READ_ONLY with no destructive operations, which reduces risk but also means no idempotent hints, confirmation patterns, or recovery guides are needed. The server lacks tool annotations entirely (no readOnlyHint, destructiveHint, idempotentHint). Parameter descriptions are either absent or 1-2 words, well below the 72-char average baseline. This is a functional but underdeveloped server suitable for read-only exploration; production use would require richer descriptions and formal output schema documentation.
Execute a basic SQL query on the code database
Get detailed information about a specific function
Get all functions defined in a specific module
Get detailed information about a specific module including function counts and statistics
Get the most frequently called functions
Get list of all modules in the database
Search for functions by name pattern
Parameter descriptions are missing or too brief. The 'limit' parameter appears in multiple tools but is described only as 'Maximum number of X to return' (8-10 chars). 'limit' params lack bounds (e.g., '1-1000') and context about result truncation implications.
Tool descriptions do not explain WHEN to use each tool or what downstream steps an LLM should take. For example, 'search_functions' says 'Search for functions by name pattern' (45 chars) but does not say: 'Use this to find functions by partial name match before calling get_function_details to retrieve full details.' LLMs need discovery guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Output schemas are not formally documented. The code defines input schemas but does not declare what each tool returns (field names, types, structure). An LLM cannot know whether 'get_function_details' returns {name, module, line_number, ...} or a flat string. Without output schema documentation, agents cannot plan chained calls or extract relevant data.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint) are declared. Even though all tools are READ_ONLY, explicitly setting readOnlyHint=true in each tool definition clarifies that these calls are safe to retry and have no side effects. This helps agents avoid unnecessary planning overhead.
'execute_query' is a generic tool that accepts a 'query_type' enum and open-ended 'filters' object. The 'filters' parameter has no schema (only 'type: object' with example properties but no required/additionalProperties enforcement). This invites LLMs to pass invalid filter combinations (e.g., name_pattern with module_id when they are mutually exclusive). The description must clarify which filter combos are valid.
No error handling guidance is documented. Tools do not describe what errors might occur (e.g., 'function not found', 'database unavailable') or how LLMs should respond. Per pattern:recovery-guide, error responses should tell the agent what to do next. Currently, an LLM has no guidance if a search_functions call returns 0 results.
'search_functions' accepts a 'pattern' with wildcard support, but the description does not explain the wildcard syntax (* vs % vs regex). The code has normalize_search_pattern() which converts '*' to '%' for SQL LIKE, but this is never documented in the tool description. An LLM must infer from trial-and-error whether '*card*' or '%card%' is expected.