Cross-AI persistent memory SaaS with MCP server for memory management, collaboration, and orchestration
Tallei AI exposes 14 tools with HTTP transport, but definition quality is significantly below production baseline. Most tools lack proper input schemas (parameters visible but not in formal JSON Schema format with type declarations). Descriptions exist but are often vague or domain-specific without explaining WHEN to use each tool or what happens on failure. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences (e.g., save_memory is destructive, recall_memories is read-only). Output schemas are not documented. Error handling and recovery guidance are absent. Tool composition shows concerning patterns: prepare_turn, recall_memories, save_memory, and remember overlap significantly (remember is an alias for save_memory), and prepare_turn combines classification, memory recall, file auto-save, and checkpoint queueing, violating single-responsibility principle. Parameter naming is inconsistent (openaiFileIdRefs vs conversation_id; some use snake_case, some camelCase). No pagination support visible despite tools that could return large result sets.
Checks if it is the specified actor's turn in a collaborative task
Creates a collaborative task with title, optional brief, first actor, and context
Submits a turn in a collaborative task with content and optional mark_done flag
Retrieves a collaborative task by ID
Ingests uploaded files (PDF, Word) with optional task context and document references
Submits answers in an orchestration session with optional auto-continue and max steps
prepare_turn violates single-responsibility principle: combines intent classification, memory recall, file auto-save, and checkpoint queueing in one tool. Should be split into separate tools (classify_intent, recall_memories, save_checkpoint) so agents can compose them independently.
No input schemas visible in source code. Parameters are documented in descriptions but lack formal JSON Schema with type declarations, constraints (min/max, enums, patterns), and required field markers. This prevents LLM validation and forces agents to guess valid formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Approves an orchestration session result
Starts an orchestration session with a goal and optional first actor preference
Prepares a response with message and optional last recall context
Unified entry point that classifies intent, recalls memories, auto-saves files, queues checkpoints, and returns replyInstructions
Recalls memories based on a query with optional filtering by type and document references
Saves a memory with kind, content, and optional metadata (alias for save_memory)
Saves a memory with specified kind, content, and optional metadata like title, key points, summary, and category
Undoes a previous memory save by document reference
Duplicate/alias tools: 'remember' is documented as an alias for 'save_memory' but both are exposed. This forces LLMs to reason about which to use, wasting tokens and inviting errors. Expose only one canonical tool.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences. recall_memories and get_task are read-only; save_memory, remember, collab_take_turn, orchestrator_answer are destructive. Agents need this metadata to plan safely and avoid retrying destructive operations.
Output schemas not documented. Tools like recall_memories and get_task return structured data but LLMs cannot see the response schema, forcing them to infer field names and types. Document return types with field descriptions.