Loading ToolBench
Local-first operating system for work: AI triage, task management, and coding agents. Automates job workflows with message ingestion from multiple channels (email, chat, issue trackers) and AI-powered task routing.
Taskuary has 30 tools with significant definition gaps. Most tools have descriptions (typically 20-80 chars), but many are vague or domain-specific jargon ('file it', 'settle', 'reach') that don't clearly convey action to an LLM. Input schemas are present for most tools but often minimal: many accept only 1-2 parameters with basic enums. Critical issues: (1) descriptions lack context on WHEN to use each tool and what it returns; (2) no documented output schemas for any tool; (3) parameter descriptions are often one-liners that don't explain format/constraints; (4) no error handling guidance visible; (5) tool names like 'settle', 'reach', 'file' are domain-specific and ambiguous without deep Taskuary knowledge. Example: 'message.file' has description 'file it - not ours, just this one' with zero input params, an LLM cannot infer what 'file' means or what happens. 'item.settle' with enum ['done','later','skip'] lacks context on what 'item' is or when to use each verb. Naming follows verb_noun pattern (positive), but verbs are often too terse.
answer the agent that is waiting - `text`
stop the running agent
add a system Taskuary talks to - `type`, `name`; created OFF and never carrying a secret, which the owner gives on the card
switch a connection off - `name`; nothing is deleted
switch a connection back on - `name`
test a connection now and say what it answered - `name`
put the item down - `verb`: done | later | skip (the item on the table is the target)
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. Every tool should document return type, key fields, and pagination (if applicable).
Ambiguous tool names and descriptions. 'message.file', 'item.settle', 'report.reach' use domain jargon without explaining action. LLMs cannot infer intent from 'file it' or 'settle'. Descriptions should state WHAT happens, WHEN to use, and WHAT is returned.
Many tools have zero input parameters but no explanation of what context they operate on. 'message.file', 'task.complete', 'agent.stop', 'review.approve' accept no params, unclear how LLM specifies which message/task/agent to target.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
keep a fact - `note`
archive it: off the pipe and closed, nothing deleted
file it - not ours, just this one
clear a SET of items from the pipe at once - takes `select` (below); read, never deleted
teach triage to file this sender or subject from now on - their mail still arrives (`scope`: sender | subject)
an exclusion rule in Settings: this sender never reaches triage again and what already arrived leaves the Timeline
create a scheduled report or workflow - `config`; the composer builds it from what the owner asked for
delete a report or workflow for good - `title`; asks first
change a report's configuration - `title`, `config`: only the keys to change (title, cron, daily_at, every_minutes, deliver, alert...)
stop a report or workflow running on its clock - `title`
change when a report reaches the owner - `title`, `reach`: always | wrong | rule
run that report again
put a paused report or workflow back on its clock - `title`
run a report or workflow now - `title` (or `source_id`); it lands in the pipe when done
send the drafted reply as it stands
remember how work like this should be ROUTED next time - `field`: kind | profile | system, and `value`. kind: coding (an agent in a checkout) | general (the assistant) | task (the owner, no agent). system: where the work actually lives when no repository here can touch it, named plainly ("ADP"). It teaches triage and moves nothing - say it when the owner tells you a verdict was wrong, or where a kind of job really belongs.
start a script by its name: walk me through my tasks | set up Taskuary | set up a report
change one setting - `setting` (its key, or `label`: part of its name) and `value`; the schema says what it takes
close the task
hand this message to an agent or put it on the list - `kind`: coding | general | task
start an agent from a brief when there is no message behind it - `kind`, `text`
open a walk-through with the assistant, for a set-up that needs digging first - `text`
split one arrival into two jobs - `text`
Parameter descriptions are minimal (1-2 sentences) and lack format/constraint details. E.g., 'kind' enum values are listed but no guidance on when to choose 'coding' vs 'general' vs 'task'. Descriptions should explain the business logic behind each option.
No error handling guidance. Tools like 'connection.test' and 'report.run' offer no recovery hints if they fail. Errors should categorize as retryable/user-fixable/fatal and suggest next steps.