Loading ToolBench
Connect coding agents to your personal Althea and her network of ML researchers.
Althea MCP has well-structured tool definitions with clear naming (verb_noun pattern) and comprehensive descriptions (150-250 chars each). All 5 tools have input schemas with typed parameters and descriptions. However, output schemas are not formally documented in the source code, responses are inferred from implementation. Parameter validation is present but error messages could be more actionable. Tool composition is sound: ask_althea and send_message_to_althea are properly separated concerns. Missing: explicit output schema documentation, enum constraints for sender parameter, and recovery guidance in error messages.
Send a message to the user's personal Althea and wait for her reply. Use this when the user wants to ask their Althea a question, share context, or request work. This reaches the same canonical Althea account used on the web and other channels. Through Althea, a request can also draw on her consent-first network of verified ML researchers. Follow-up calls continue the configured MCP thread.
Fetch the recent transcript of any conversation owned by this user. This reads conversations from the user's canonical Althea account, including web/app and other channel conversations, not only the configured MCP thread. Messages are returned chronologically. Use `search_althea_conversations` first when the conversation ID is unknown.
Get recent messages from the configured conversation with Althea. Use this to inspect history or retrieve a response after `send_message_to_althea`.
Find this user's Althea conversations across every channel. Use this before `get_althea_conversation_log` when the user identifies a prior conversation by title or topic rather than its conversation ID. With no query, this returns the most recently active conversations.
Output schemas not formally documented. Responses are inferred from implementation (dicts with id, conversation_id, sender, content, created_at, cycle fields) but not declared in tool metadata. LLMs cannot plan downstream operations without knowing response structure.
sender parameter in get_althea_messages accepts string|null but lacks enum constraint. Description says 'filter by "user", "assistant", or "system"' but no formal enum in schema. LLMs may pass invalid values; validation happens at runtime with ValueError.
Error messages lack recovery guidance. TimeoutError in ask_althea says 'She may still be working; call `get_althea_messages` to check later' (good), but ValueError for invalid sender/limit just states the constraint without suggesting how to fix it. ValueError('sender must be one of...') should guide the LLM to retry with valid value.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Send a message to the user's personal Althea without waiting. Use this for context, notes, or requests that do not need an immediate response. The message is real and Althea will process it; use `get_althea_messages` to retrieve her eventual reply.
Pagination not fully documented. get_althea_messages and search_althea_conversations accept limit (1-100) but no offset/cursor or total_count returned. If results exceed limit, agent cannot fetch next page or know if more exist. Violates paginated-result pattern.
ask_althea has a hard timeout (poll_timeout, default likely 30s) but no guidance on what to do if Althea is slow. Error message suggests calling get_althea_messages later, but agent may not know to retry or how long to wait. Should document expected response time and retry strategy.