Loading ToolBench
MCP server that appends what you did to the checklist of the newest log file in a directory
Two well-named tools with excellent, detailed descriptions that read as LLM instructions. Both tools have complete input schemas with proper types and descriptions. Tool annotations (idempotent_hint, destructive_hint, read_only_hint) are present and correct. Output schemas are documented in descriptions. Error handling is explicit (no_dir, no_file, duplicate, created, written). Main gaps: no pagination/limits (not applicable here), no batch variants, and output structure not formally schematized in JSON Schema format. Naming follows verb_noun pattern (append, check). Descriptions are 194 - 392 chars, well within the 10 - 1024 baseline. All parameters have descriptions and types.
Record ONE finished piece of work in the user's log for today. Call this the moment a task is actually done — a fix landed, a change was pushed, a question was answered — and once per piece of work. Do not call it to plan something, to take a note, or to save a partial result. The item is appended as a completed entry to the checklist of the newest file in the log directory. That directory is configured when the server starts: you do not choose it, you cannot pass it, and you will not be told what it is. Write `description` as one plain sentence in the past tense, in the language the user writes their log in, naming what changed and — for a bug — why it happened. Leave out issue keys, links and branch names unless the user asks for them. The call is idempotent: repeating the same sentence returns `duplicate` and writes nothing, so retrying after an error is safe. If today's file has no checklist yet, one is started at the end of it and you get `created` instead of `written` — say so when you report back, since the file gained a list it did not have. The log file itself is never created. If the directory or the file is missing you get `no_dir` or `no_file`: report that to the user in one line and stop — do not create a file, do not look for the log yourself, and do not ask the user for the path. Returns the status, the log file's NAME (never its path) and the exact line written. Set `dry_run` to see that line without writing it.
Check that a log file with a checklist can be found right now. Use it to diagnose an `append` that came back `no_dir` or `no_file`: it tells you whether the server is misconfigured or the user has simply not started today's log yet. It takes no arguments and changes nothing — a file with no checklist is reported as `no_checklist` here, not started, which only `append` does. Returns the log file's NAME and how many items its checklist already holds. It is not a way to read the log — the items themselves are never returned, and no other tool returns them either. Do not call it before every append; the append reports the same conditions by itself.
Output schema not formally documented in JSON Schema. Descriptions state what is returned (status, file NAME, line count) but no structured output schema is visible in code. LLMs cannot reliably parse unstructured text responses.
No pagination or result limits. Not critical for this domain (worklog is append-only, check returns one count), but if check ever returns item details or append returns multiple matches, lack of pagination could blow context.
Tool annotations present but incomplete. append has idempotent_hint=true and destructive_hint=false, but read_only_hint is missing (should be false). check has no annotations at all (should have read_only_hint=true).
Error messages are documented in descriptions but not formally returned as structured error objects. LLMs must parse text like 'no_dir' or 'no_file' from unstructured responses rather than receiving a typed error field.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
append description mentions 'dry_run' parameter but does not explain what 'dry_run=true' returns vs 'dry_run=false'. Does it return the line without status? Does it skip the file write? Ambiguous for LLM planning.