MCP server for Obsidian vault graph navigation and ranking
Vault Graph MCP shows solid foundational work with clear naming conventions and documented schemas. All 8 tools follow verb_noun patterns (graph_*) and have explicit JSON Schema definitions with required parameters marked. However, parameter descriptions are inconsistent, some parameters lack detail on format/constraints, and output schemas are defined in TypeScript interfaces but not documented in the tool registration visible in the source. No tool-level error handling guidance or recovery hints are present. The server targets a well-defined domain (Obsidian vault graph navigation) and implements coherent composition, but lacks the polish needed for >70: descriptions could be LLM-optimized further, parameter constraints (e.g. limits on `limit`, format of `node` IDs) are not enforced or clearly explained, and no acknowledgment of edge cases or failure modes.
Build or rebuild the vault graph index. Use force=true to rebuild even if cache is valid.
Find hub nodes (most connected notes). Use mode to select by incoming, outgoing, or total connections.
Get isolated (orphan) nodes with no incoming or outgoing connections.
Get all neighbors (linked notes) for a given node. Returns raw, unranked results.
Get neighbors ranked by relevance. Returns scored results with explanations.
Get detailed information for a single node, including all incoming and outgoing connections.
Find related nodes (2-hop neighbors, excluding direct neighbors). Useful for discovering related content.
Parameter constraints and ranges not enforced or documented in descriptions. Tools accept numeric limits (limit, page size) with no stated bounds, LLMs may pass absurd values (limit=999999) causing timeout or crash.
Output schemas documented only in TypeScript type definitions, not visible in tool registration. LLMs cannot see return field structures (e.g., what fields are in ScoredNode? Is there a score field? Is there explanation text?). This forces LLMs to guess output shape.
No error handling guidance or recovery hints in descriptions. When a tool fails (e.g., node not found, invalid limit), LLMs receive only an error message with no actionable next step. Descriptions do not warn about failure modes or suggest recovery tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Search nodes by title or tags. Returns matching notes with matched fields highlighted.
Parameter descriptions lack format specifications. 'node' parameter documented as 'file path relative to vault root' but no examples of valid formats (does '.md' extension matter? Case sensitivity? Nested paths with '/'?). This invites LLM format errors.
Tool descriptions lack dependency hints or composition guidance. E.g., graph_search does not hint that the LLM should call it first to discover node IDs before calling graph_get_node. This forces inefficient multi-step planning.
No distinction between tools that accept natural identifiers (titles, tags) vs opaque node IDs. All tools require node ID (file path), forcing the LLM to search first. Consider accepting note titles or tags as fallback parameters for convenience.