Loading ToolBench
Lightweight MCP server for maintaining coding context across sessions
jot-mcp has explicit tool definitions with schemas and descriptions, but falls short of production quality. All three tools have schemas and descriptions present, but descriptions are minimal (10-30 chars) and lack context on when/why to use each tool. Parameter descriptions exist but are terse. No documented output schemas. Error handling is present but generic. The naming is mostly sound (jot, list_jots, context) but 'list_jots' could be 'search_jots' if search is the primary use. Overall, this is a D/C boundary server, functional but lacks the depth expected of production tooling.
List or delete contexts
Create, update, or delete jots
List/search jots with filters
Minimal tool descriptions (<40 chars). 'Create, update, or delete jots' lacks context on when to use this tool vs list_jots or context, and does not explain what 'jots' are or their lifecycle. LLMs need 50-200 char descriptions to disambiguate tool selection.
No documented output schema. Callers cannot see what fields are returned. Handler returns plain text (responseText) for all tools, but no structured documentation of response shape (object keys, types, nested fields). This forces LLMs to infer structure from unstructured text.
'jot' tool bundles three distinct operations (create, update, delete) behind a single 'operation' enum. This violates single-responsibility: the tool name does not clearly signal what it does (is it creating, updating, or deleting?), forcing LLMs to reason about the operation parameter first. Consider splitting into create_jot, update_jot, delete_jot.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
'context' tool also bundles list and delete operations (enum: [list, delete]). Similar to 'jot', this mixes read and destructive operations, making the tool ambiguous. Split into list_contexts and delete_context.
Parameter descriptions are terse and lack constraints. E.g., 'ttlDays' has description 'Days until expiration (0 = permanent)', no mention of valid range (is negative allowed? max 365?). 'tags' is described as array of strings but no guidance on format, length, or reserved names. Missing enum/pattern constraints invite invalid input from LLMs.
Error handling returns plain text errors but no structured classification. In handlers.ts (not shown but inferred from catch block), error response is { content: [{type: 'text', text: `Error: ${error.message}`}], isError: true }. This tells LLM an error occurred but not whether to retry, ask user, or abort. No recovery guidance.
Destructive operation (delete context, delete jot) is not guarded by confirmation or dry-run. 'context' tool with operation=delete will permanently erase a context. No confirm_before_execute pattern. Agents can destroy data by accident.
No pagination documented for 'list_jots'. Even though limit param exists, no mention of offset/cursor, total count, or what happens if results exceed limit. Large result sets will bloat context and degrade LLM reasoning (pattern:paginated-result baseline: return total count, next_cursor, limit).