Loading ToolBench
MCP Knowledge Graph Memory Server with Supabase + pgvector for semantic search
This MCP server implements a knowledge graph memory system with 9 tools. Tool naming follows verb_noun convention clearly (create_entities, delete_relations, search_nodes). Descriptions are present and reasonably detailed for most tools (average ~80 characters, within acceptable range). Parameter schemas are well-structured using Zod validation with type definitions and descriptions. However, there are notable gaps: (1) Output schemas are NOT documented, responses are returned as raw JSON without typed field definitions, making it hard for LLMs to plan downstream calls; (2) Error handling is minimal, the withLogging wrapper catches errors but returns only generic 'Error: {message}' responses without recovery guidance or categorization; (3) Some parameter descriptions lack detail on constraints (e.g., entityType, relationType accept free-form strings with no enum values or format guidance); (4) No pagination support despite read_graph and search_nodes potentially returning large result sets; (5) Parameter relationship documentation is missing (e.g., when deleting observations, which entity names are valid?). Tool definitions themselves are explicit and registered directly in src/server.ts using server.tool(), so not inferred.
Add observations to existing entities
Create entities in the knowledge graph with names, types, descriptions, and observations
Create relations between entities in the knowledge graph
Delete entities from the knowledge graph
Delete specific observations from entities
Delete relations from the knowledge graph
Output schemas are not documented. Tools return raw JSON objects without type definitions for fields (e.g., read_graph returns { entities: [...], relations: [...] } but LLMs cannot see this structure in advance). LLMs cannot plan downstream tool calls or extract required IDs (chaining_ids) without knowing response structure.
Enum constraints missing for string parameters. 'entityType' and 'relationType' accept free-form strings with no validation, LLMs cannot know valid values and will hallucinate types. Should declare as enums or at least document allowed values in description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Retrieve specific entities by name
Read the complete knowledge graph including all entities and relations
Search for entities matching a query using semantic search
Error handling lacks recovery guidance. The withLogging wrapper returns 'Error: {message}' but does not categorize errors as retryable, user-fixable, or fatal. No guidance on next steps (e.g., 'Entity not found. Try search_nodes() first.'). Errors should be actionable.
No pagination support. read_graph returns entire graph without limits; search_nodes has no limit/offset params. Large graphs will blow context windows. Baselines show paginated tools return 20-50 items with a next_cursor or total_count.
Destructive operations lack confirmation or dry-run. delete_entities, delete_observations, delete_relations execute immediately with no confirm_before_execute pattern. Agents may make mistakes, these tools should support a --dry-run flag or explicit confirmation step.
Parameter relationship documentation missing. For delete_observations, the valid entityName values depend on what entities exist, but there is no hint to call open_nodes or search_nodes first, or guidance on what happens if entityName does not exist.
Tool descriptions do not clarify mutation semantics. For create_entities and add_observations, descriptions should state 'Adds new entities to the knowledge graph' vs 'Updates existing entities if name matches.' The distinction matters for idempotency and agent planning.