Loading ToolBench
MCP server for flowlio agents - a project management and task tracking system with inter-repository communication via issues and memory management
Strong foundation with 12 well-named tools using clear verb_noun patterns (list_, get, create_, update_, block_, unblock_, answer_, check_, remember, recall). All tools have descriptions (avg ~120 chars, within 10-1024 baseline). Input schemas are present and properly typed with JSON Schema. However, output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling lacks recovery guidance. Some parameter descriptions could be more explicit about constraints and formats. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels.
Adds a message to an issue thread, and closes it when asked.
Records that a task cannot move until another task of THIS project reaches a status. When it does, the blocked task is released, comes back to todo if this is what had blocked it, and shows up in check_inbox. There is no cross-project form: to depend on a sibling repo, open an issue.
What awaits the agent, with no parameter at all.
Asks a sibling project of the team a question, and returns its reference. Use it when only the other repo can answer — for your own work, open a task.
Opens a task in the current project's backlog and returns its key. Status defaults to todo and priority to normal.
What a reference points at: a task with its note thread, or an issue with its message thread. The kind field says which. This is what you read to pick a subject back up.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. E.g., list_tasks returns what fields? Does it include task_id, title, status? Required for tool composition.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with Risk levels (READ_ONLY, WRITE, REVERSIBLE) in comments but not exposed to MCP clients. Clients cannot determine safety/retry semantics.
Error handling lacks recovery guidance. No indication of retryable vs. fatal errors, or what the LLM should do next. E.g., if create_task fails due to invalid deadline format, should the LLM retry, ask the user, or call a different tool?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
The questions exchanged with sibling projects: the ones addressed to you and the ones you asked. Closed ones are excluded by default.
The current project's backlog, newest task first. Descriptions are not included: read one with get.
Lists or searches the project's memory.
Writes one entry, and retires what it replaces.
Lifts one recorded dependency by hand, without waiting for the blocking task to move. The other dependencies of the task stay in place. Lifting one that was already lifted is not an error.
Changes a task of the current project, and records what was done on the way. Only the fields you pass change; the others are left as they are. ref + note alone is enough: that is how you leave a trace without changing anything else. An archived task can no longer be changed.
Parameter 'ref' in get, update_task, block_task, unblock_task, answer_issue lacks explicit format/constraint documentation. Description says 'e.g. CORE-34' but does not state: Is it required? Can it be a bare number? What is the regex pattern?
check_inbox has empty input schema (no properties). Description says 'with no parameter at all' but does not explain what it returns or when to call it. Minimal documentation for a discovery tool.