Loading ToolBench
Persistent memory infrastructure accessible from anywhere - Cloudflare Worker MCP Server
Mind Cloud has a well-structured tool set with consistent naming (mind_* prefix) and reasonable descriptions, but suffers from critical gaps in parameter documentation and output schema specification. Of 15 tools examined, naming is generally clear (verb_noun pattern with mind_ namespace), but parameter descriptions are sparse or missing entirely for many fields. Most critically: output schemas are not documented anywhere in the source, we cannot see what these tools return, making it impossible for LLMs to chain calls or validate results. Additionally, several tools are highly generic (mind_write accepts 13 optional parameters with minimal constraint documentation) and lack clear guidance on when to use one vs another (mind_orient vs mind_ground distinction is unclear). Error handling is not visible in the code snippet provided. The server uses STDIO transport only, which is a hard blocker for production use.
Current context layer - situational awareness
Edit an existing observation, journal, or image
Track, check, or clear relational state toward someone
Second call on wake - get active threads, recent work, recent journals
Check cognitive health stats
Read or write identity graph
List all entities, optionally filtered by type or context
No output schemas documented. Tools return structured data but response format is not specified in the source code. LLMs cannot know what fields to expect, cannot chain tool calls reliably, and cannot validate results.
mind_write is a mega-tool accepting 13 optional parameters with different behaviors based on 'type' enum. Undocumented dependencies (e.g., which fields apply for type='entity' vs type='observation' vs type='image') force LLMs to guess. Should split into separate tools: write_entity, write_observation, write_relation, write_journal, write_image.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
First call on wake - get identity anchor, current context, relational state
Read an entity with all its observations and relations
Mark an emotional observation as metabolized - link it to a resolution or insight that processed it
Search memories using semantic similarity
Sit with an emotional observation - engage with it, add a note about what arises. Increments sit count and may shift charge level.
Surface emotional observations by resonance - what's emotionally alive right now based on current mood and hot entities. Optional query for directed associations.
Manage threads (intentions across sessions)
Write to cognitive databases (entity, observation, relation, journal, image)
Parameter descriptions are generic or missing for most tools. 'status' in mind_thread has no description (what are valid values?). 'context' appears in 7 tools but is never explained. 'action' enums lack guidance on which to choose when. LLMs cannot distinguish when to use 'add' vs 'update' in mind_thread without clearer docs.
mind_orient and mind_ground both describe themselves as initialization/awareness calls with vague success criteria. Descriptions do not explain WHEN to call each one, what conditions trigger each, or how their outputs differ. This violates the 'when to use' requirement from pattern:tool-description.
mind_identity and mind_context lack 'required' field declarations for their action enums. Also missing constraint documentation: what is a valid 'section' for mind_identity? What is a valid 'scope' for mind_context? Unbounded free-text fields invite garbage input from LLMs.
mind_sit and mind_resolve accept three mutually exclusive lookup methods (observation_id, text_match, query) but do not document this explicitly. If an LLM passes two, the behavior is undefined. Should state: 'Provide exactly one of: observation_id, text_match, or query.'
mind_search supports pagination-like parameters (n_results) but no documented limit, default, or max. What if LLM passes n_results=10000? Response could exhaust context. Should document: 'default 10, max 100' and update description accordingly.
mind_list_entities documents a default limit of 50 in description but schema shows no numeric constraint (min/max). If LLM omits 'limit', is it 50? Is there a server-side cap? Ambiguity causes unpredictable behavior.
No error handling guidance visible in tool definitions. Tools return status codes or errors but descriptions do not tell LLMs what to do if a call fails. E.g., if mind_write fails due to duplicate entity, should the LLM retry, update instead, or ask the user? Missing recovery paths.
mind_edit accepts three mutually exclusive lookup methods (observation_id, journal_id, image_id) plus text/description matches, but does not clarify: if LLM passes both observation_id and journal_id, which takes precedence? Dependencies undocumented.