Loading ToolBench
Exposes ContextGraph as MCP (Model Context Protocol) tools so that Claude, GPT, and other MCP-aware agents can store, recall, relate, watch, and review knowledge-graph memories over stdio JSON-RPC.
Server has 8 tools with mostly complete schemas and descriptions. Naming follows verb_noun pattern consistently (contextgraph_store, contextgraph_recall, etc.). Descriptions are present and reasonably detailed (average ~130 chars), exceeding the 10-char minimum but below the optimal 50-200 char LLM-optimized range. All tools have proper JSON Schema input definitions with types and descriptions for parameters. However, tool descriptions lack situational context (WHEN to use) and recovery guidance. Output schemas are not formally documented, responses are inferred from descriptions. Error handling is minimal; tools do not specify what errors they can return or how to recover. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Several tools expose complex or internal concepts (claim_id, access_list, delivery_mode enums) without sufficient guidance on valid values or dependencies. The server targets a knowledge-graph domain with strong composition (tools chain well via entity/claim IDs) but parameter validation rules and error classification are underspecified.
Compile a governed, token-budgeted context pack from ContextGraph memories. Returns a summary, included/conflicting claims, source provenance, and explanations — all filtered by the requesting agent's access policies.
Get pending notifications for the current agent. Returns undelivered notifications from standing queries.
Recall memories from the ContextGraph by semantic query. Returns matching claims with confidence scores and related entities.
Find relation paths between two entities in the knowledge graph. Returns chains of claims that connect entity_a to entity_b.
Review (attest or challenge) a claim in the knowledge graph. Attesting increases trust; challenging flags it for removal.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. LLMs cannot distinguish read-only tools from write operations without explicit hints. contextgraph_store, contextgraph_watch, contextgraph_review, and contextgraph_session_start should be marked destructiveHint=true; recall, relate, compile_context should be marked readOnlyHint=true.
Output schemas are not formally documented in the tool definitions. Callers cannot see what fields will be returned (e.g., does contextgraph_recall return claim_id, confidence_score, entities?). This forces LLMs to infer structure and increases hallucination risk.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Start a new coding session in ContextGraph. Returns a session object with a session_id for recording events and checkpoints.
Store a memory in the ContextGraph knowledge graph. The content is parsed into claims, entities, and relations.
Create a standing query (subscription) that triggers notifications when new claims match the query.
Tool descriptions lack situational context. They state WHAT the tool does but not WHEN to use it or how it relates to similar tools. E.g., contextgraph_recall vs contextgraph_compile_context, when should the LLM choose one over the other? Are they idempotent? Can they be retried safely?
Error handling and recovery guidance is absent. Tools do not specify what errors they can return, error codes, or what the LLM should do next. E.g., contextgraph_store should document: 'Returns error if content exceeds 10KB or if visibility level is not valid. On validation error, LLM can retry with shorter content or adjust visibility.'
contextgraph_watch has enum parameter 'delivery_mode' with opaque values ('pull', 'websocket', 'webhook', 'a2a') but does not explain what each mode means or when to use each. The 'filters' object is additionalProperties=string with no schema for expected keys. This forces LLMs to guess valid filter names and webhook_url format.
contextgraph_store parameter 'metadata' is additionalProperties=string but no examples or constraints are given. LLMs have no guidance on what keys are expected (e.g., is 'source', 'author', 'domain' valid?). Same issue with 'filters' in contextgraph_watch.
contextgraph_relate parameter 'max_depth' has no bounds. Should specify min=1, max=5 (or similar) to prevent runaway graph traversals. Same for contextgraph_recall 'limit', no max bound specified.
contextgraph_compile_context parameter 'token_budget' defaults to 4000 but no guidance on what happens if real response exceeds budget. Does it truncate? Fail? Paginate? This ambiguity forces LLMs to guess and retry.
contextgraph_review and contextgraph_watch require claim_id and query, respectively, but no guidance on how to obtain these IDs. Do they come from contextgraph_recall output? From contextgraph_compile_context? This dependency is undocumented.