Loading ToolBench
A Go-based MCP server that provides tools for workflow execution, activity status monitoring, auto-improvement capabilities, and coding agent session management with virtual browser tools
Server defines 2 tools with reasonable descriptions and clear intent. Both tools have input schemas present and documented parameters. However, several definition quality gaps prevent a higher score: (1) Parameter descriptions in schemas are sparse, most input params lack inline descriptions beyond the parameter name itself; (2) Output schemas are not explicitly documented for either tool; (3) Error handling and recovery guidance are not visible in tool descriptions; (4) Tool descriptions are adequate (70-150 chars) but lack WHEN to use and prerequisite guidance that LLMs require for confident selection. The capture_context tool exhibits tighter parameter documentation than get_activity_status, but both lack output structure documentation.
Capture durable user-supplied runtime business context for this workflow. Use only after the user confirms the item should be remembered across runs, and only when the Workflow Profile allows business-context accumulation. Writes to knowledgebase/context/context.md. Keep the capture concise and authoritative. Use for persistent rules, preferences, constraints, assumptions, examples, ICP filters, approval rules, brand voice, or domain context that workflow steps must respect. Do not use for one-off instructions, general chat memory, workflow-discovered facts that belong in knowledgebase/notes, or execution recipes that belong in learnings.
Return a JSON snapshot of currently running workflow executions and workflow schedules. Use this when the user asks what workflows, background runs, or cron jobs are running right now.
Output schemas not documented. Both tools return data structures, but the exact fields, types, and nesting are not visible in tool registration. LLMs cannot plan downstream calls or extract the right data without knowing what fields to expect.
Input schema parameters lack descriptions in JSON Schema. The 'section' and 'context_text' parameters in capture_context have descriptions in the pattern field (not in the schema), but get_activity_status has an empty properties object with no field documentation at all. LLMs rely on parameter descriptions to understand what each field controls.
Tool descriptions lack WHEN to use guidance and prerequisites. The capture_context description is rich with domain context (mentions knowledgebase, workflow, business context) but get_activity_status is minimal. Neither explains when to prefer one tool over an alternative or what preconditions must be true before calling.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No error handling guidance in tool descriptions. Neither tool explains what errors can occur, how to recover, or what the LLM should do if the call fails. Error responses should tell the agent what to do next (retryable, user-fixable, or fatal).
capture_context has optional 'section' parameter with a default ('General' when empty) but the schema does not formalize the default value in JSON Schema (no 'default' key). LLMs cannot infer defaults from descriptions alone and may pass explicit empty strings.