Loading ToolBench
Security-focused LLM memory storage MCP server for tracking security assessments, vulnerabilities, intelligence, and security operations with MITRE ATT&CK mapping and compliance frameworks
TinyBrain has 16 tools with complete JSON schemas and descriptions visible in internal/app/server.go. However, critical quality gaps significantly reduce the score: (1) No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk classifications in the source. (2) Descriptions are functional but often under 100 chars and lack LLM-optimized guidance on WHEN to use tools or dependencies between them. (3) Multiple redundant tools (search_memories/search_memory, get_related_memories/get_related_entries, create_memory/store_memory) that waste LLM reasoning cycles. (4) Parameter descriptions lack format guidance, range constraints, and example valid values. (5) Output schemas are not documented, search_memories returns implicit structures not formally specified. (6) Security-domain terminology (threat_level, mitre_tactic, intelligence_type) is well-applied but error recovery guidance is absent. (7) No confirmation-request pattern for destructive operations like delete_memory. Tools are functional but fall short of production-grade LLM-optimized quality.
Create a snapshot of the current context and memory state for the session
Alias for store_memory tool - Store a new piece of information in memory with security-focused categorization
Create a relationship between two memory entries
Create a new security-focused session for tracking LLM interactions
Create a new task progress entry for tracking work within a session
Delete a memory entry permanently
Retrieve a specific memory entry by ID
Redundant tool definitions: create_memory is identical to store_memory; search_memory aliases search_memories; get_related_entries aliases get_related_memories. These duplicate tools force LLMs to reason about which to pick, wasting tokens and increasing error likelihood. Split or remove aliases.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) in definitions. Source shows risk classifications (READ_ONLY, WRITE, DESTRUCTIVE) but these are not exposed as tool hints. LLMs cannot infer safety boundaries without explicit annotations. Delete_memory and other destructive tools lack confirmation guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | 2024-11-05+ | v1 |
Alias for get_related_memories - Get memories related to a specific memory entry
Get memories related to a specific memory entry
Retrieve a session by ID
List all sessions with optional filtering
Search for memories using various search strategies optimized for security tasks
Alias for search_memories - Search for memories using various search strategies optimized for security tasks
Store a new piece of information in memory with security-focused categorization
Update an existing memory entry with new information
Update the progress of an existing task
Delete_memory has only 30-char description ('Delete a memory entry permanently') with no recovery guidance. Offers no error guidance or undo pattern. Critical destructive operation lacks confirmation-request pattern.
Output schemas not documented. Search_memories, list_sessions, and get_related_memories return complex structures (implicit arrays, pagination fields, memory objects) but no formal response schema is visible. LLMs cannot plan downstream calls without knowing what fields to expect.
Parameter descriptions lack constraint guidance. E.g. 'priority_level 0-10' is stated in descriptions but format is not schema-enforced. Enum fields like threat_level (low, medium, high, critical) accept string values but valid options should be explicitly enumerated in parameter type/enum, not just in description text.
No dependency hints in descriptions. For example, search_memories accepts a 'session_id' filter but does not state 'To find a session ID, call list_sessions() first.' This forces LLMs to discover multi-step flows independently, increasing latency and error risk.
No error recovery guidance in tool descriptions. Tools like update_memory do not state what errors might occur (e.g., 'memory_id not found') or how to recover.
Required parameters not minimized. Many tools require multiple fields (e.g., create_memory needs session_id, title, content, category, all required). No smart defaults offered. This forces agents to gather more input than necessary; consider defaulting category='note', content_type='text', priority=5, confidence=0.5.