Loading ToolBench
Auto-generate code metadata sidecars for LLM-optimized navigation. No AST dumps, no embeddings — just structured YAML.
fmm presents a functional MCP server with 11 read-only tools for code analysis. However, multiple critical quality gaps prevent a higher score. All tools have descriptions (good), but descriptions are generic and brief (avg ~60-80 chars, below the 194-char baseline). Parameter descriptions are present but sparse, most lack guidance on format, range, or constraints. Input schemas are visible and properly typed, but lack sufficient detail to guide LLM invocation. Output schemas are undocumented entirely. Error handling is present (tool_errors.rs shows helpful error recovery suggestions like recommending fmm_list_files), but this pattern is inconsistently applied. Tool naming follows verb_noun convention (good: fmm_search, fmm_read_symbol, fmm_list_files), but several tool descriptions are ambiguous about when to use them vs. related tools (fmm_search vs fmm_similar vs fmm_dupes are functionally overlapping). The toolset lacks composition patterns, no batch operations, no mention of which tools chain together, and responses lack documented fields needed for downstream calls. Overall: serviceable for a specialized domain tool, but below production-grade quality for general-purpose agent deployment.
Get dependency graph for a file with upstream and downstream dependencies
Find duplicate symbols across the codebase by name, signature, kind, or directory
Get the outline/structure of a file showing all symbols defined in it
Get a glossary of terms across the codebase with optional filtering and precision control
List all exports from the codebase, with optional file filter
List files in the codebase with optional directory filter and filename pattern matching
Look up a specific export by name to see where it is exported from and what imports it
Output schemas undocumented. No tool specifies what fields are returned or how to chain results into downstream tools. LLMs cannot infer which fields to extract for follow-up calls.
Parameter descriptions lack constraint guidance. 'loc' in fmm_search is described as 'Filter by lines of code (e.g. >500, <100, =200, >=50, <=1000)', this embeds examples (violates pattern). Should state format formally: 'Operator-prefixed integer: >, <, =, >=, <= followed by 1-10000 LOC threshold.'
Tool descriptions are too brief and lack context on when to use them. fmm_search, fmm_similar, and fmm_dupes all find symbols but differ subtly. Descriptions do not explain the distinction, forcing LLMs to guess or try each one (wasted tokens). Avg description length ~65 chars; baseline is 194 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get manifest metadata for the analyzed codebase
Read the source code of a symbol by name
Search for symbols by term, with optional filters by export status, imports, lines of code, and dependencies
Find symbols similar to a given name by signature, kind, directory, or test status
fmm_manifest has no parameter description. Input is {} (no params), but the tool description does not explain what metadata is returned or when to call it.
No pagination / result limiting guidance. fmm_list_files, fmm_list_exports, and fmm_search can return large result sets, but no mention of how many results are returned or if pagination is supported. Without limits, LLMs risk context explosion.
Error recovery is demonstrated in tests (tool_errors.rs) but not consistently applied. Only fmm_dependency_graph, fmm_read_symbol, fmm_file_outline, and fmm_search show error guidance. Other tools lack documented recovery paths.
No tool composition documented. No mention of which tools are typically called together, what IDs/fields chain between tools, or multi-step workflows. Agents must discover composition through trial and error.