Loading ToolBench
MCP server for SwarmVault, a local-first knowledge compiler with graph outputs and optional provider-backed workflows. Exposes graph querying, path finding, and graph analysis tools over the Model Context Protocol.
SwarmVault MCP exposes 6 graph analysis tools with reasonable names and partial schemas, but critical gaps undermine production readiness. All tools follow verb_noun naming (query_graph, blast_radius, find_graph_cycles, graph_diff, graph_stats, validate_graph_artifact), which is strong. Descriptions are present and moderately detailed (range: 80-160 chars), meeting the 10-1024 character baseline. However, input parameter documentation is severely incomplete: the graph parameter in all 6 tools is described only as 'GraphArtifact' with no explanation of structure, required fields, or format. The complex 'options' object in query_graph has nested properties documented as descriptions (e.g. 'Graph traversal algorithm') but lacks type information for the parent object itself. No output schemas are documented anywhere in the visible code, LLMs cannot infer what these tools return or plan downstream composition. Error handling is not visible; no guidance on failure modes, retryability, or recovery steps. All tools are read-only (no state mutation), which is safe, but the lack of destructive operations means no confirmation patterns are needed.
Compute the blast radius of a graph node - the set of nodes that would be affected by changes to that node
Find and report cycles in a graph artifact
Compute the difference between two graph artifacts
Compute statistics about a graph artifact
Query a graph artifact with a natural language question, returning ranked matches for nodes, pages, and hyperedges
Validate a graph artifact for structural and logical consistency
No output schema documentation. Tools do not declare what they return, making it impossible for LLMs to plan composition or extract specific fields. Example: query_graph returns 'ranked matches for nodes, pages, and hyperedges' but the actual structure (array of objects? nested hierarchy? what fields?) is undocumented.
GraphArtifact parameter lacks structural documentation. All 6 tools accept 'graph' as an object of type 'GraphArtifact' but provide no description of what fields it must contain, what the schema is, or how to construct it. LLMs cannot invoke these tools without guessing the structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Options parameter (query_graph) has nested properties but no type annotation on the parent object. Properties like 'traversal', 'budget', 'semanticMatches', and 'filters' are described individually, but the 'options' object itself lacks a type declaration (e.g. 'type: object', 'required: [...]', 'additionalProperties: false'). This violates JSON Schema conventions.
No error handling documentation. Tool descriptions and schemas do not explain failure modes, what errors can occur, or how to recover. For example, if a graph is malformed, does the tool return a structured error or throw? If a node ID is not found in blast_radius, what happens?
graph_diff expects two GraphArtifact objects but provides no guidance on what 'difference' means or how the output is structured. Is it a list of added/removed nodes? A delta object? A textual report?
query_graph's searchResults parameter is described as 'Array of SearchResult objects from semantic search' but SearchResult structure is not documented. What fields does it contain? Is this parameter required or optional? When would an LLM provide it vs omit it?
No pagination or result limits documented. Tools like graph_stats and find_graph_cycles may return unbounded output (e.g., 'all cycles in the graph' could be thousands). No documentation of result caps, pagination support, or token-aware limits.