Loading ToolBench
MCP server that implements memory stored in MongoDB
The server defines 10 tools with MongoDB-backed memory operations. Naming is generally clear and action-oriented (create_*, get_*, update_*, delete_, find_*). Descriptions exist for all tools and parameters, but have significant limitations: (1) repetitive hint text ('If this is your first memory operation...') appears in 9 of 10 tool descriptions, inflating token cost without adding per-tool value; (2) most descriptions lack guidance on when to use a tool vs. alternatives (e.g., distinction between get_entity and find_entities); (3) schemas are present but incomplete, array items in 'entities' parameter lack type definition, and output schemas are not formally documented. Error handling is not visible in the provided code. The server uses FastMCP framework with proper parameter typing in Python, but schema documentation is sparse. Overall, the definitions are functional but inefficient and would benefit from refactoring hint text, documenting output schemas, and differentiating tool purposes more clearly.
Create entities in memory. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices.
Create a relationship between two entities. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices.
Delete a single entity by its name. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices.
Delete a relationship between two entities. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices.
Find entities matching the query criteria. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices.
Get a single entity by its name. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices.
Boilerplate hint text repeated in 9 of 10 tool descriptions. The hint ('If this is your first memory operation...') adds ~100 chars per tool (900 total) without per-tool differentiation. This wastes tokens and dilutes signal during LLM tool selection.
Output schemas not documented. Code shows tools return Mapping/dict but no formal schema specifies what fields to expect (e.g., does create_entities return {success: bool, inserted_ids: [str], ...}?). LLMs cannot plan downstream calls without knowing return structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Get the current memory structure. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices.
Get relationships from the database. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices. IMPORTANT: This tool is designed to return all relationships up to the specified limit. If you need to filter relationships, process the results in your code.
🚨 RECOMMENDED FIRST STEP: Get a quick start guide with examples for using this MCP service. This guide MUST be retrieved by the agent in the following cases: 1. When memory-related operations are requested but no memory context exists 2. When starting a new conversation about memory management 3. When uncertain about memory organization principles 4. Before making decisions about data categorization 5. When memory usage patterns need to be verified The agent should NOT retrieve this guide if: 1. Memory context is already provided and clear 2. The current operation follows an established pattern 3. The guide was already retrieved in the current conversation
Update a single entity by its name. 💡 HINT: If this is your first memory operation in this session, consider calling get_usage_guide() first for best practices.
No error guidance. Code shows error responses exist (create_error_response imported) but descriptions do not state what can go wrong or how to recover. E.g., create_entities might fail if entity name is duplicate, is this retryable? User-fixable? Fatal? LLMs have no strategy.
'update_entity' expects MongoDB update syntax (e.g., {\'\$set\': {...}}) but no example provided in description. LLMs unfamiliar with MongoDB will hallucinate invalid syntax like {field: value} instead of {\'\$set\': {field: value}}.
Destructive operations (delete_entity, delete_relationship) do not mention irreversibility in descriptions and offer no confirmation/dry-run pattern. Agents may delete critical data without safeguards.
'find_entities' has no pagination support (no offset/cursor parameter, no total_count returned). Description says 'limit' defaults to 10 but max not specified, unbounded queries risk timeout or context-window exhaustion if agent increases limit arbitrarily.
'relationship_type' parameter uses custom DSL format ('type:key1=value1,...'). While documented, LLMs struggle with bespoke syntax and often omit properties or malform key=value pairs. Consider structured parameters instead (type, properties dict).
'get_relationships' offers no filtering (by from_entity, to_entity, or type). Description states 'filtering must be done in code,' forcing the agent to fetch all relationships and process client-side. Inefficient and wastes tokens.
No distinction between 'get_entity' (by name) and 'find_entities' (by query). Descriptions do not explain when to use each. An LLM might call find_entities with query={name: 'entity1'} instead of get_entity(name='entity1'), wasting a round-trip.