Loading ToolBench
Home-view-graph: a knowledge graph over a directory you choose, built to prove itself wrong
Five read-only tools with complete JSON schemas and detailed descriptions. Tool names are clear action verbs (mesh_search, mesh_neighbors, mesh_path, query, mesh_explain). Descriptions are substantive (100-300+ chars) and explain WHAT, WHEN, and WHAT-RETURNS. All parameters have types and descriptions. However, output schemas are not documented, LLMs cannot see what fields to expect in responses. Error handling guidance is minimal. No parameter validation constraints (enums, ranges, patterns) visible in schemas. The query tool's grammar documentation is extensive but lives in description text rather than structured constraints.
Which models answered a query, at what rank, and how the results were fused. Use this when a result looks surprising: it shows whether a model was missing rather than merely unhelpful.
Cross-model edges touching a node, in either direction.
Shortest path between two mesh nodes. Returns null when there is none within max_depth -- absence of a path is an answer, not an error.
Federated search across the homegraph models. Returns hits with the model each came from, and a status of 'complete' or 'partial'. A partial result means a model did not answer; counts and ranking are incomplete and must not be read as a full answer.
One structural query over a single model's graph, in homegraph's closed query language. Grammar: MATCH (a:label)-[e:REL]->(b:label) [WHERE cond AND cond] [AS OF 'YYYY-MM-DD'] RETURN a.prop, b.prop. Conditions use = != < <= > >= PREFIX CONTAINS, or `a NAMED 'basename'` to look a node up by filename. There is no OR, no DISTINCT, no aggregation and no variable-length path; anything outside the grammar is refused with a message naming what is missing, never partially interpreted. A status of 'ambiguous' means a NAMED lookup matched several files and none was chosen -- ask again with one of the candidates. A status of 'partial' means some returned edge was inferred rather than stated; the warning names how. The same language also asks two cross-model questions, which take no model and read the whole federation: ASK dangling_mentions (mention edges whose target file is no longer on disk) and ASK unmentioned_files (file-level nodes no mention edge points at). A status of 'refused' on those means the corpus was not fully readable and the answer would have been a guess -- the warning names which store did not answer.
Output schemas not documented. LLMs cannot see what fields mesh_search, mesh_neighbors, mesh_path, query, and mesh_explain return. This forces LLMs to guess field names for downstream reasoning and risks context loss.
No parameter validation constraints. Schemas lack enums, min/max bounds, or regex patterns. E.g., 'limit' has no upper bound (could be 1M+), 'depth' unbounded, 'max_depth' unbounded. LLMs can pass absurd values that break performance.
Error handling guidance missing. Tools return status codes ('complete', 'partial', 'ambiguous', 'refused') but descriptions do not explain what the LLM should do when status != 'complete'. Should guide retry, user input, or fallback.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
query tool grammar documented in description text, not structured constraints. LLMs cannot parse the grammar rules (MATCH/WHERE/AS OF/RETURN syntax, no OR/DISTINCT/aggregation) from prose. Should be in a separate grammar reference or structured parameter.
mesh_neighbors and mesh_path descriptions are terse (70-80 chars). Do not explain when to use them vs mesh_search, or what 'cross-model edges' means to an LLM unfamiliar with the homegraph domain.