Loading ToolBench
MCP server for Mesh, a knowledge graph and note-taking system with source-code indexing, semantic search, and graph traversal capabilities
Mesh provides 8 well-named, read-only tools with clear descriptions (avg 156 chars, within 10-1024 baseline). All tools have input schemas with typed parameters and descriptions. However, output schemas are not documented in the source code provided, and error handling guidance is absent. Tool names follow verb_noun convention (mesh_code_search, mesh_neighbors). Descriptions explain WHAT and WHEN but lack recovery guidance. Parameters are well-described with constraints (e.g., limit defaults and maxima), but no enum constraints are visible. Security is strong (no credentials in params, read-only operations), but composition could be tighter, mesh_code_context fuses two indexes, which is good, but no batch variants exist for agents calling tools in loops.
Fuses the two indexes: resolves a symbol like mesh_code_search, then for each match returns the NOTES that reference it (decisions/gotchas about that code). This is 'what do we know about this function' - code plus the institutional knowledge around it, in one call. Linked notes are scope-filtered like any read.
Returns the call-graph neighbors of a symbol id: what it calls (callees) and what calls it (callers). Edges exist for Go; other languages return empty lists.
FTS over the source-code symbol index, ranked by name match. Returns symbol cards with a file:line locator so an agent can jump straight to a definition instead of grepping the tree. Deliberately separate from mesh_search so locating a function never competes with note retrieval or the tier-0 budget.
Returns one note's community + its members (when id is given), or the community overview (when it is not), for orienting before a search.
Returns the typed neighborhood of a note out to a small depth, so an agent can walk the graph one hop at a time instead of fetching whole files. Performs undirected BFS recording the shortest hop and the edge that first reached each neighbor.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure. mesh_code_search, mesh_neighbors, mesh_community, and secret tools all lack documented return types.
No error handling guidance. Tools lack recovery hints (e.g., 'If symbol not found, try mesh_code_search with a partial name'). Errors are not categorized as retryable, user-fixable, or fatal.
mesh_community parameter 'id' is optional but behavior differs (community overview vs. specific community). Undocumented dependency between presence/absence of 'id' and response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Returns the NAMES + rotation metadata of the attached vault's secrets (never a value). Read-only metadata, so it is not write-gated.
Reports whether a vault is attached and how to use it, without any network call and without ever echoing the key. It is the whoami of the broker.
Mints a short-lived, single-use, destination-bound capability token for a secret the agent can never read. Minting spends the team's credential, so it is gated behind the write role. Returns a token + the proxy URL; the real secret is injected by Dockyard's proxy at forward time, never returned here.
No enum constraints visible for parameters that accept known sets of values. E.g., mesh_code_search 'languages' array could benefit from an enum of supported languages.
mesh_secret_use is the only write tool but lacks confirmation/dry-run pattern. Minting a credential token is irreversible, should support a preview or confirmation step.