Loading ToolBench
MCP server exposing MindGraph vault operations over HTTP, allowing agents to read and manipulate task graphs, notes, and their relationships
MindGraph exposes 10 well-named tools with complete JSON schemas and clear descriptions. All tools follow verb_noun naming (list_, search_, get_, create_, append_, link_, update_). Descriptions are substantive (100 - 250 chars), explaining WHAT the tool does and WHEN to use it. Schemas are properly typed with required/optional fields and additionalProperties=false. However, parameter descriptions lack actionable constraints (e.g., no enum for edge kinds, no format for date strings, no min/max for limit). Error handling is minimal, tools return plain text success messages but lack recovery guidance for failures. No tool annotations (readOnlyHint, destructiveHint) despite clear read/write distinction. Output schemas are not documented, forcing LLMs to infer response structure.
Append text to the end of a node's body. Strictly additive: every other field, and every byte already in the body, is left exactly as it was. Agents may not rewrite a node — that rule exists so a human's words cannot be silently replaced — but a running record of one piece of work belongs on that work, not scattered across new nodes.
Create a note in the vault. A note is a document with no task facet — it has a kind (e.g. reference, rfc, memory) but no status or place in the ready queue.
Create a task in the vault. A task is a node with a status (todo, doing, done) and an optional deadline. The task starts in the todo state and is ready to work on if it has no dependencies.
Read one node from the user's MindGraph vault in full — its body, kind, status, deadline, assignee, and what it depends on. list_ready_tasks gives you a line; some nodes are a page, and the reason for a piece of work is usually in the body.
Create an edge between two nodes. The kind determines the relationship: depends_on means the source cannot start until the target is done, relates_to is a weaker connection, and context_for means the target is background reading for the source.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY or WRITE in metadata but not in schema. LLMs cannot infer safety properties from tool definitions alone.
Parameter constraints missing. 'kind' in link_nodes accepts 'depends_on|relates_to|context_for' but no enum constraint. 'status' in update_status accepts 'todo|doing|done' but no enum. 'due' date format not specified (YYYY-MM-DD inferred from description only). 'limit' has no min/max bounds.
Output schemas not documented. Tools return text responses but LLMs cannot plan downstream calls without knowing response structure. E.g., search_notes returns 'id, title, kind, first line' but no JSON schema defines this.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
List all tasks in the ready queue: open tasks with no blockers, sorted by due date. A task is ready when its dependencies are finished and nothing is waiting on it to start.
Find notes related to a given node: its dependencies, dependents, and notes that relate to it. Useful for understanding the context around a piece of work.
Search the vault by title and body text. Returns the id, title, kind, and first line of each match. Searches are case-insensitive substring matches.
Find edges the vault has evidence for and does not have: notes that name each other in prose without linking, and `[[links]]` written to a name that never resolved. Give it a node to ask what that one should connect to, or omit it to sweep the whole vault. It proposes only - create the edge with link_nodes if the suggestion is right, and ignore it if it is not.
Change a task's status, deadline, or assignee. The status must be one of todo, doing, or done. Omit fields you do not want to change.
Error handling lacks recovery guidance. Tools return plain success text but no error messages guide LLM recovery. E.g., if node not found, what should the LLM do next? No 'try search_notes()' guidance.
Parameter descriptions lack actionable format/range guidance. 'due' is described as 'date string (YYYY-MM-DD)' in text but not enforced via JSON Schema format. 'assignee' accepts any string with no validation hint.