Loading ToolBench
MCP server for integrating with Omi API to retrieve and create conversations and memories
Three tools with complete Zod schemas and descriptions. Naming follows verb_noun pattern (read_*, create_*). Descriptions are adequate (100-200 chars) but lack actionable context for LLM selection. Parameters are typed and described, but lack constraints (enums, ranges, patterns). Output schema is undocumented, responses return raw JSON without field-level documentation. Error handling is basic (throws generic errors without recovery guidance). No tool annotations (readOnlyHint, destructiveHint). Missing idempotency guidance for create_omi_conversation.
Creates a new Omi conversation with text content and metadata
Retrieves user conversations from Omi with pagination and filtering options
Retrieves user memories from Omi with pagination options
Output schemas undocumented. Tools return JSON.stringify({conversations}) and JSON.stringify({memories}) without field-level documentation. LLMs cannot plan downstream calls or extract structured data reliably.
No parameter constraints. 'limit' accepts any number (should be 1 - 1000); 'offset' unbounded; 'statuses' is free-form string (should be enum or documented format). LLMs will pass invalid values.
Error handling lacks recovery guidance. Errors throw generic messages ('Failed to read conversations: ...') without suggesting next steps. LLMs cannot self-correct or retry intelligently.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
No tool annotations. create_omi_conversation is destructive (WRITE risk) but lacks destructiveHint annotation. read_* tools lack readOnlyHint. Agents cannot infer safety properties.
Descriptions lack dependency hints and selection context. 'Retrieves user conversations...' does not explain when to call this vs read_omi_memories, or what prerequisites exist (e.g., must have user_id first).