Loading ToolBench
MCP server for the Rewind personal data API. Syncs and serves data from services that track your life: listening (Last.fm + Apple Music), running (Strava), watching (Plex + Letterboxd), collecting (Discogs), and reading (Instapaper).
Three tools with well-structured schemas and detailed descriptions. get_health and search have comprehensive parameter documentation with enums and constraints. semantic_search includes sophisticated guidance on when to use it vs. search(mode:hybrid). All tools are READ_ONLY with proper risk annotations. However, output schemas are not explicitly documented in the visible code, only input schemas are defined. Tool descriptions are excellent (194 - 250 chars, well above baseline), and parameter descriptions are thorough. No security issues detected (no secrets in params). Composition is sound: search and semantic_search are distinct tools with clear use cases, and get_health is a utility. Missing: explicit output schema definitions and error handling guidance.
Check the health and sync status of the Rewind API. Returns API status and last sync times for each data domain.
Search across all domains (listening, running, watching, collecting, reading). Three ranking modes: keyword (default) uses FTS5 full-text search across all domains; semantic uses Voyage AI embeddings for paraphrased / meaning-based recall (reading domain only); hybrid fuses both (reading domain only). Use semantic or hybrid when the user describes what an article was ABOUT rather than quoting its words. **Prefer `mode: hybrid` whenever the user mixes a topic with a recalled keyword or a publisher hint** ("the ESPN piece about Ichiro", "the WSJ article on EVs") — semantic alone does not see source domains and can drop the publisher signal entirely. When a result is the article the user is asking about, follow up with `get_article(id)` to render the rich inline article card — do not stop at the search-result text response.
Semantic search over the reading domain using Voyage AI embeddings. Use when the user describes the gist or topic of an article they remember rather than quoting exact words — e.g. "article about a former SNL writer" or "piece about tech layoffs". Returns articles ranked by cosine similarity with a score in [0,1]. Reading domain only. **Important: this tool does NOT see source domains** — embeddings only encode title + description + body. If the user mentions a publisher (ESPN, NYT, WSJ, Atlantic, etc.) or a recalled keyword, prefer `search(mode: "hybrid", ...)` so FTS picks up that signal. **If the top scores cluster within ~0.03 of each other, raise `limit` to 15+** — the right match may sit at position 6+ and approximate-nearest-neighbor noise can swap items at the boundary. When the top result is the article the user is asking about, follow up with `get_article(id)` to render the rich inline article card; if the top score is low (~0.4 and below) or you are unsure which match is right, list the top 2-3 candidates and ask the user to disambiguate before rendering.
Output schemas not documented. Input schemas are well-defined (Zod), but return types for each tool are not visible in the provided code. LLMs cannot plan downstream calls or extract fields without knowing what fields are returned.
Error handling guidance missing. Tools do not document what errors can occur, how to recover, or what the LLM should do next. E.g., search with invalid domain enum is caught, but semantic_search with no results or low confidence scores lacks guidance.
semantic_search description is very long (450+ chars) and mixes multiple concerns: when to use it, limitations (no source domains), and recovery heuristics (raise limit if scores cluster). Should be split into description + separate parameter guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2025-06-18+ | v2 |
search tool description includes detailed guidance on mode selection (keyword vs semantic vs hybrid) but does not explicitly state what each mode returns or how results differ. LLMs may not understand why hybrid is preferred for mixed queries.
No pagination guidance in search results. Tool accepts limit (1 - 50, default 10) and page (default 1), but description does not explain total count, next_cursor, or how to iterate through large result sets.