Loading ToolBench
A Go-based MCP server providing tools for agent execution, including filesystem operations, web access, memory management, cron scheduling, and team delegation workflows
Sageclaw has 5 tools with mixed quality. Three tools (memory_search, memory_get, tool_search) have complete schemas and reasonable descriptions (50-100 chars). Two workflow tools (_workflow_analyze, _workflow_plan) have vague descriptions and unclear semantics, _workflow_analyze appears to be a decision gate but lacks guidance on when/why to call it, and _workflow_plan's task structure is complex but underdocumented. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. Error handling and recovery guidance are absent from all tool descriptions. Parameter descriptions are minimal; e.g., 'tags' in memory_search lacks explanation of how tags boost results or interact with filter_tags.
Analyze whether this request should be delegated to team members or handled directly. Call this BEFORE _workflow_plan.
Create a task plan for team delegation. Each task is assigned to a team member. Call _workflow_analyze first.
Retrieve a specific memory by ID
Search stored memories by natural language query
Search for available tools by keyword. Returns full tool schemas for matching tools. Use when you need a tool that isn't in your current tool list.
Workflow tools lack clear semantics and recovery guidance. _workflow_analyze description ('Analyze whether this request should be delegated...') does not explain when an LLM should call it, what triggers delegation, or how to interpret the confidence score. _workflow_plan's task structure (subject, assignee, description, blocked_by) is complex but undocumented, no guidance on task dependencies, assignee resolution, or error handling if an assignee is unavailable.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk profiles. memory_search, memory_get, and tool_search are READ_ONLY; _workflow_plan is WRITE. Annotations enable agents to reason about side effects and retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Parameter descriptions are minimal or missing context. 'tags' in memory_search lacks explanation of boosting semantics; 'filter_tags' lacks clarification on AND vs OR logic. 'blocked_by' in _workflow_plan references task IDs ($TASK_0) but does not explain how to construct or validate these references.
No error handling or recovery guidance in any tool description. If memory_search returns no results, should the LLM retry with different tags? If _workflow_plan fails to assign a task, what should happen? Descriptions must guide recovery.
Workflow tool naming violates verb_noun convention. '_workflow_analyze' and '_workflow_plan' use underscore prefix (suggesting internal/private) and lack clear action verbs. Better names: 'analyze_delegation_request', 'create_task_plan'. Underscore prefix signals to LLMs that these are meta-tools, not user-facing actions.