Loading ToolBench
Slack-based human approval for MCP tool calls. Multi-vtable cdylib plugin that gates tool execution, notifies via Slack, and handles approval callbacks.
This is a plugin-based tool-gate system with 3 tools. All three have descriptions and input schemas visible in src/lib.rs. However, critical issues severely limit quality: (1) Tool names lack action verbs, 'tool_gate', 'approval_notifier', 'http_route' are nouns/infrastructure terms, not verb_noun patterns like 'gate_tool_call' or 'send_approval_request'. (2) Parameter descriptions are minimal (1-2 sentences) and lack actionable constraints, no enums, ranges, or format specs. (3) Output schemas are not documented; responses are inferred from code comments only. (4) No error handling guidance, what happens if Slack API fails? If signature validation fails? (5) Security concerns: bot_token and signing_secret are config-injected but no mention of how they're protected in transit or storage. (6) The http_route tool accepts a generic 'payload' object with no schema constraints, LLMs cannot validate Slack interactivity payloads without explicit field documentation.
Posts the approval request to Slack via chat.postMessage and returns the channel/ts for audit linking
Receives Slack interactivity callbacks (button clicks), validates Slack's request signature, and POSTs the resolution to the gateway's HMAC-signed direct callback URL
Pre-dispatch gate that matches tool calls against operator rules and returns PendingApproval with target_notifiers=[self] for matching tools
Tool names are infrastructure nouns, not action verbs. 'tool_gate', 'approval_notifier', 'http_route' do not follow verb_noun convention. LLMs cannot infer intent from names alone. Rename to 'gate_tool_call', 'send_approval_notification', 'handle_slack_callback'.
Output schemas are not documented. Code comments describe behavior (e.g. 'returns the channel/ts for audit linking') but no formal schema is provided. LLMs cannot plan downstream calls or extract fields without explicit output documentation.
Parameter descriptions lack actionable constraints. 'deadline_secs' has no range (1 - 3600?). 'channel' accepts 'id or name' but no format spec. 'payload' is a bare object with no field documentation. Constraints must be explicit so LLMs can validate inputs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | <=2025-11-25 | v2 |
No error handling guidance. What does tool_gate return if a rule regex fails to compile? What if Slack API returns 429 (rate limit)? What if signature validation fails? Error responses must guide LLM recovery.
http_route tool accepts generic 'payload' object with no schema. Slack interactivity payloads have required fields (type, trigger_id, actions, etc.). Without explicit field documentation, LLMs cannot construct valid payloads.