Loading ToolBench
Terminal-native AI agent runtime — parallel orchestration, reactive subagents, MCP, autonomous supervision
SynapsCLI exposes 4 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-150 chars, mostly adequate) and input schemas with type definitions. However, parameter descriptions are sparse or missing context. The activate_tools tool has a critical security concern: it accepts a 'confirmed' boolean parameter that the description explicitly states 'model-authored parameter cannot self-approve', this is a design flaw that invites misuse. Output schemas are not documented. Error handling is minimal. Tool naming follows verb_noun convention (load_skill, search_skills, search_tools, activate_tools), which is good, but the tools form a tightly coupled skill/tool discovery system with limited standalone utility. No pagination, no result limits documented, no recovery guidance in error cases.
Activate tools for use in the current session. Requires host confirmation authority. Activates the exact requested identity only.
Load a skill to guide your behavior for the current conversation. Skills provide structured guidelines, checklists, and best practices. Call this when a task would benefit from a specific methodology.
Search available skills by keyword. Returns bounded stable skill ids with compact descriptions. Pass a returned id to load_skill to load exactly that skill.
Search available tools by keyword. Returns bounded stable tool ids with compact descriptions. Pass a returned id to activate_tools to activate exactly that tool.
activate_tools accepts 'confirmed' boolean but description warns 'model-authored parameter cannot self-approve', this is a security anti-pattern. LLMs will pass confirmed=true, bypassing intended authorization. Implement server-side permission checks instead of relying on LLM honesty.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., skill_id from search_skills, tool_id from search_tools). Responses are opaque.
search_skills and search_tools lack pagination parameters (limit, offset, cursor) and result-count documentation. No guidance on result limits. Large result sets will blow context windows.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Parameter descriptions are minimal. 'skill' param in load_skill says 'Skill to load: a stable id from search_skills, a bare name, or plugin:skill', good. But 'query' in search_skills/search_tools lacks detail on matching behavior, result ordering, or what 'bounded' means.
No error handling guidance. If load_skill fails (skill not found), what should the LLM do? Retry? Call search_skills? No recovery path documented.