Loading ToolBench
Local-first code intelligence MCP server for symbol resolution, call graph analysis, dependency tracking, memory management, and semantic search across codebases
GraphMind MCP server demonstrates solid tool design with clear naming conventions (gm_* prefix), comprehensive parameter schemas, and well-structured descriptions. All 11 tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun patterns (gm_query, gm_fn, gm_deps, gm_impact, gm_fn_impact, gm_map, gm_cycles, gm_memory_search, gm_memory_add, gm_memory_list, gm_session_analyze). Descriptions are detailed and contextual (avg ~150 chars), explaining WHEN to use each tool and how it differs from related tools. However, output schemas are not documented in the provided source, limiting downstream tool chaining visibility. Error handling guidance is absent, tools do not describe recovery paths or error categories. Memory tools (gm_memory_add, gm_session_analyze) are write operations but lack confirmation/dry-run patterns.
Detects circular import/dependency chains between files in the project. Returns each cycle as an ordered list of files. Use when diagnosing build issues, layering violations, or before major refactors.
Returns all symbols a file imports or uses (outgoing dependencies). Use before refactoring to understand what a file depends on. Reverse direction: gm_impact (what depends on this file).
Returns full source code + direct callers + direct callees for ONE symbol. Use when you need to read the implementation. Returns more data than gm_query (full source vs 5-line snippets). Pass file= or kind= when the name is ambiguous.
Returns all transitive callers of a function (full blast radius at symbol level). Use before changing a function's signature or behavior. Complements gm_impact (file-level) — this is symbol-level. Pass file= when the name is ambiguous (matches multiple symbols across the codebase).
Returns all files that transitively depend on a given file (incoming, reverse of gm_deps). Use before deleting or changing a file's public API to understand blast radius.
Output schemas not documented. Tools return data but downstream tool chaining visibility is zero, LLMs cannot plan multi-step calls or extract required IDs for follow-up operations.
Write operations (gm_memory_add, gm_session_analyze) lack confirmation/dry-run patterns. Agents can persist incorrect facts without review, risking corrupted memory state.
No error handling guidance. Tools do not describe what errors are retryable, user-fixable, or fatal. LLMs receive raw failures with no recovery path.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Lists the most connected files in the project ranked by edge count (imports + importers). Use as the first step to understand project architecture. Returns file names with connectivity scores — not a full dependency graph.
Save a fact to persistent memory. Use proactively when decisions, patterns, conventions, preferences, or important context emerge. No confirmation needed — saves immediately.
Lists all memory entries for a project without filtering (paginated). Use to audit what has been saved or when you don't have a specific search keyword. For keyword-based recall, prefer gm_memory_search.
Searches saved memory entries by keyword (decisions, patterns, conventions, bugs). Call at session start with relevant topic keywords to recall prior context. Returns ranked entries with type and tags. Use gm_memory_list to browse all entries without filtering.
Resolve a symbol to its location + direct callers/callees as compact 5-line snippets (no full source). Use when you need the call graph but not the implementation. For full source, use gm_fn. Use file= or kind= to disambiguate overloaded names.
Batch-save multiple facts from a session in one call with automatic dedup. Pass an array of facts (content, type, tags, priority). Skips entries too similar to existing ones (Jaccard>0.80). Use at session checkpoints or end-of-session instead of multiple gm_memory_add calls.
gm_session_analyze accepts nested object array (facts) with optional type/tags fields, but schema clarity is reduced. Nested structures increase LLM parsing errors.
Pagination parameters (limit, offset) present but no total_count or next_cursor documented in output. LLMs cannot determine if more results exist or how to iterate safely.