Loading ToolBench
Read-only MCP server for searching and reading a WhyNote account
Four read-only tools with complete JSON schemas and reasonable descriptions. All tools have proper input validation and error handling. However, descriptions are terse (avg 85 chars, below 194-char baseline), parameter descriptions are minimal or absent, and output schemas are undocumented. No tool annotations (readOnlyHint, idempotentHint). Tools follow verb_noun naming but lack context about when to use each vs. alternatives. Error messages are actionable but recovery guidance is sparse.
Read one day's full note body and etag.
Read existing note days on one side of an anchor, newest first.
Search note lines using the same case-insensitive substring scan as the web app.
List todo items with done, age, and overdue fields from the note service.
Output schemas undocumented. LLMs cannot infer what fields to expect from search, todos, read_day, or recent_days responses. This forces agents to guess at response structure and risks failed downstream tool calls.
Parameter descriptions missing or minimal. 'q' in search has a description, but 'offset' does not. 'includeDone' in todos lacks context. 'anchor' and 'dir' in recent_days are terse. LLMs cannot infer parameter semantics from names alone.
Tool descriptions are terse (55 - 70 chars). Baseline is 194 chars. Descriptions lack context about when to use each tool vs. alternatives (e.g., when to call search vs. read_day vs. recent_days). LLMs cannot disambiguate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
No tool annotations. Tools lack readOnlyHint, idempotentHint, or destructiveHint. Agents cannot infer safety properties and may incorrectly assume tools have side effects.
Error messages are actionable but lack recovery guidance. E.g., 'NOTE_URL is not configured' tells the user to set an env var, but does not suggest alternative tools or next steps for the agent.