Loading ToolBench
Production MCP server for Plaud knowledge timeline. Exposes the full Chronos system as MCP tools for OpenAI-compatible clients. Runs over stdio transport.
The server provides 11 tools with documented parameters and descriptions, but exhibits significant quality gaps. Most tools are properly named with action verbs (search_, get_, list_, run_), and parameter schemas are visible with type definitions. However, descriptions are often generic, output schemas are not explicitly documented in the source, and error handling guidance is minimal. The codebase shows partial implementation (source cut off mid-exception handler), making full assessment difficult. Tools like 'ask_chronos' and 'run_pipeline' have reasonable descriptions, but many lack specificity about return structure and failure modes. Parameter descriptions exist but are sometimes redundant with names rather than adding actionable guidance.
RAG — semantic search for relevant events plus Gemini answer synthesis. Ask a question about your recordings and get a comprehensive answer with sources.
Get knowledge graph entities and relationships extracted from events.
Get full details for a specific recording including all extracted events.
Get system statistics including recording counts, processing status, and category distribution.
Get the event timeline for a specific date or date range. Returns all events grouped by recording for the given date(s).
List all topic categories extracted from events with their frequencies.
Output schemas not documented. Tools return JSON strings but LLM cannot determine expected fields, types, or structure without trial. E.g., search_events returns {results: [...], total}, but this is only evident from the code implementation, not the tool registration.
Error handling and recovery guidance absent. The search_events tool has a try/except that catches 'Exce' (code truncated), but no error recovery hints are provided to the LLM. Tools do not return error classifications (retryable, user-fixable, fatal) or suggest next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
List all Chronos recordings with their status and event counts.
Health check — returns pong if server is alive.
Trigger the ingest/process/index pipeline to sync and process new recordings from Plaud.
Search Chronos events using semantic vector search. Finds events from voice recordings that match your query. Supports filtering by category and date range.
Health check for all services (database, vector store, AI models, Plaud API).
Parameter descriptions lack actionable constraints. 'limit' is described as 'Max results to return (1-50, default 10)' but this is enforced in code (max(1, min(50, limit))), not documented as a schema constraint. Enums like category should use formal enum constraints rather than free-form strings describing valid values.
Generic tool descriptions. 'get_stats' is described as 'Get system statistics including recording counts, processing status, and category distribution' but does not explain when to call it vs. get_topics or system_status. 'get_topics' says 'List all topic categories extracted from events with their frequencies' but LLM cannot distinguish this from search_events results.
No pagination documentation in output. list_recordings supports pagination (limit, offset), but output schema does not indicate whether a next_cursor, has_more, or total_count is returned. Agents cannot determine when to fetch more results.
Timeout protection implemented but not advertised to LLM. Tools have @_with_timeout() decorators (30s default, 5s for ping), but the tool descriptions do not warn that timeouts will occur if services are slow. LLM cannot decide between retry vs. fallback strategies.