Loading ToolBench
PostgreSQL-based RAG Memory MCP Server with Supabase - knowledge graph + semantic search
The server defines 23 tools with reasonable coverage of RAG+knowledge-graph operations. Most tools have descriptions (194-char baseline met for many), and input schemas are present and structured. However, there are systematic gaps: output schemas are NOT documented anywhere; many parameter descriptions are generic or lack format/constraint details; error handling is not evident in the tool definitions; tool names are mostly consistent but some lack clarity (e.g., 'openNodes' vs 'searchNodes' distinction is unclear); and several tools combine multiple concerns (e.g., processDocument does store+chunk+embed in one call, violating single-responsibility). The server lands in the 'fair to good' range, functional definitions but notable gaps in LLM-guiding descriptions and output contracts.
Add new observations (facts, notes, details) to existing entities. Use this to enrich entities with additional information over time. All observations should be in English for consistency.
Split a document into chunks
Create new entities in the knowledge graph. Use this to store structured information about people, projects, technologies, concepts, or any important items. Entity names and observations should be in English for consistency.
Create relationships between existing entities in the knowledge graph. Use this to connect related concepts, show dependencies, or build knowledge networks. Relationship types should be in English.
Delete documents and their chunks
Delete multiple entities and their associated relationships
Output schemas not documented. 23 tools define inputs but zero tools document what fields, types, or structure they return. LLMs cannot plan downstream tool chains or extract relevant fields without knowing return types. This violates the schema documentation baseline (100% of A+ tools have documented return types).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Delete specific observations from entities
Delete specific relationships from the knowledge graph
Generate embeddings for all entities
Generate embeddings for document chunks
Extract keywords and terms from a document
Search and return detailed context with related entities and documents
Get the complete knowledge graph structure with all entities and relationships
Get statistics about the knowledge graph including entity counts, relationship counts, and other metrics
Search documents using hybrid semantic and full-text search
Link entities to a document for knowledge graph integration
List all documents
Get complete details of specific entities by their exact names. Returns entity type, all observations, and related connections. Use this to retrieve full information about known entities.
⭐ RECOMMENDED: Store document with full pipeline (store → chunk → embed). Use this for adding any documentation, code examples, or knowledge. Content should be in English for optimal search performance. Automatically chunks text and generates embeddings.
Get the complete knowledge graph structure with all entities and relationships (backward compatibility alias for getGraph)
Rebuild the full-text search index for documents
Search for entities in the knowledge graph by name or type. Use English keywords for best results. Returns matching entities with their types and observations.
Store a document (without chunking/embedding)
Destructive tools (deleteEntities, deleteRelations, deleteObservations, deleteDocuments) lack confirmation/dry-run patterns and error recovery guidance. Descriptions do not warn that operations are irreversible or guide LLM recovery if deletion fails. No mention of consequences or recommended confirmation steps.
Many parameter descriptions are generic or missing. storeDocument, listDocuments, chunkDocument, embedChunks, embedAllEntities, rebuildSearchIndex lack detailed descriptions of what they do and when to use them. Examples: 'Store a document (without chunking/embedding)' is terse; 'Generate embeddings for document chunks' lacks context on when/why to call it.
openNodes and searchNodes overlap in responsibility. Both search for entities; openNodes retrieves 'by exact names' while searchNodes accepts a 'query'. The distinction is unclear, an LLM must reason about whether to use fuzzy search (searchNodes) or exact lookup (openNodes), inviting wrong tool selection. One canonical tool would be clearer.
processDocument combines three distinct operations (store + chunk + embed) in a single tool. This violates single-responsibility: agents cannot choose to store without chunking, or chunk without embedding. Should split into separate tools so agents compose as needed.
readGraph is a duplicate of getGraph with a vague description ('backward compatibility alias'). Two tools doing the same thing waste LLM reasoning. Remove the alias or clarify when to use each.
Pagination and limits not uniformly documented. searchNodes defaults to limit=10; hybridSearch to limit=5; others have no limits. If a tool returns unbounded results, it risks context window overflows. Document max result counts and offer offset/cursor pagination in descriptions.
No error handling guidance in tool descriptions. When createRelations is called with non-existent entities, what happens? When deleteEntities fails, how should the LLM recover? Descriptions must answer: what errors are possible, how to detect them, and what to do next.