Loading ToolBench
AI Assistant Memory System - Pure MCP Tool for storing and retrieving project context, code snippets, and development insights
DevMind MCP demonstrates moderate definition quality with all 15 tools clearly named and described, but significant gaps in schema completeness, parameter validation, and error handling guidance. Tool names follow verb_noun convention well (create_session, record_context, search_context), though some lack differentiation (search_context vs search_project_context, record_context vs record_session_context). All tool descriptions are present (10-200 chars range, averaging ~90 chars), meeting baseline requirements. However, input schemas visible in the prompt show basic type and description coverage but lack critical constraints: no enums for type fields (code|conversation|error|insight|design|bug_fix|feature_request should be enum), no numeric bounds (limit defaults to 10/50 but lacks min/max), no format specifications for file_path or output_path parameters. Parameter descriptions are present but generic, 'Optional: tags for categorization' lacks guidance on expected tag format or count. Output schemas are undocumented, there is no visible specification of what search_context or get_project_context actually return beyond implied structure. Error handling is minimal: no guidance on what happens when session_id does not exist, when project_path is invalid, or how to retry. The server includes AI enhancement modules (QueryEnhancer, AutoMemoryClassifier) suggesting advanced capability, but these are not reflected in tool descriptions, creating a disconnect between implementation and interface.
Create a new session for organizing and managing context records within a project
Delete a specific context record from the database
Export contexts from a project to JSON or other formats for backup or sharing
Generate an interactive HTML visualization of the project's memory graph showing relationships between contexts
Get comprehensive context about a project including all recorded contexts, sessions, and relationships
Get statistics about a project's memory including context count, quality metrics, and usage patterns
Get detailed information about a session including contexts recorded and timeline
No enum constraints on type fields. Parameters like 'type' accept free-form strings ('code', 'conversation', 'error', etc.) without formal enum declaration. This invites LLM hallucination of invalid types like 'hypothesis', 'design_doc', 'brainstorm' not in the actual set.
Numeric parameters lack bounds. 'limit' defaults to 10 or 50 but no minimum/maximum stated. 'max_contexts' and 'max_nodes' are unbounded, allowing LLMs to request millions of results, causing DoS or context window exhaustion.
Output schemas are undocumented. No visible specification of what search_context, get_project_context, get_session_info, or get_project_statistics return. LLMs cannot plan downstream tool calls or extract nested fields without documented return structures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 13 | - | v1 |
Import contexts from a JSON file into a project
Index a codebase to extract and store file information and code structure for context retrieval
List all sessions for a project with summary information
Record a development context (code snippet, conversation, error, insight) to memory for future reference and retrieval
Record context within an active session with automatic quality assessment and deduplication
Search for relevant contexts using semantic/vector search or keyword matching
Search for contexts within a project using vector/semantic search or keywords
Update metadata and tags for an existing context
No error guidance. Tools lack documented recovery paths. E.g., delete_context says 'Delete a specific context record' but does not state what happens if context_id does not exist, should the LLM retry, fall back, or query available contexts first?
Duplicate tool intent. search_context and search_project_context have nearly identical signatures and descriptions. Similarly, record_context and record_session_context both record development context with overlapping type enums. LLMs will waste reasoning cycles deciding between them, and selection errors are likely.
Parameter descriptions are generic and lack format guidance. 'file_path' is described as 'Optional: file path if context is code-related' without specifying whether it must be absolute, relative, or a pattern. 'output_path' similarly lacks format guidance. LLMs may pass invalid paths.
No idempotence guarantee. delete_context is destructive but lacks a dry-run or confirmation step. Agents retry on ambiguous failures, repeated calls with the same context_id could cause unexpected results.
Dependency hints missing. import_contexts description does not mention that project_path must exist or that the file_path must be valid JSON. record_context does not state that session_id must have been created via create_session first. Undocumented dependencies cause silent misuse.
No pagination documented for list_sessions despite accepting limit and offset. No indication of total count, next_cursor, or whether results are sorted. Large project histories could exceed the context window.
Quality score threshold parameter (min_quality) is undocumented. search_context and search_project_context accept 0-1 range (implied) but no guidance on what quality means or typical values. LLMs may pass 0.5 and receive different results from different tools.