Loading ToolBench
A Model Context Protocol server for managing Slack channels and conversations. Provides tools for managing bookmarks, canvases, channel settings, message destinations, and other channel administration features.
This server has 10 Slack-focused tools with mixed quality. Tool naming follows verb_noun conventions well (list_, add_, remove_, create_, read_, edit_, set_). Descriptions are detailed and contextual, often exceeding 100 characters and explaining WHEN to use each tool. However, several critical gaps exist: (1) All input schemas lack type definitions beyond basic string/object wrappers, parameters like 'title', 'url', 'canvas_id' have descriptions but no explicit type constraints; (2) Output schemas are completely undocumented, we know what tools do but cannot see what they return, breaking the tool-chaining pattern; (3) No enum constraints on parameters that should have them (e.g., 'operation' in edit_canvas has enum in schema, which is good, but most string params lack enums); (4) Error handling guidance is absent, no recovery instructions if a bookmark is not found or canvas edit fails; (5) No idempotency or confirmation hints for destructive operations like remove_bookmark, despite that tool being marked IRREVERSIBLE.
Pin a link to the top of this conversation as a bookmark, where everyone in it will see it from now on — only when someone here asks you to. The bookmark bar is a shared surface with very little room, and it is the first thing anyone sees. Never add one on your own initiative, never add one because a link seems useful, and never add one to make a point. If a person asks you to bookmark something, do it once; if it is not obvious which link or what to call it, ask rather than guessing. Adding is not the same as posting: if they just want to read something now, put the link in your reply instead.
Create a new canvas in this channel — a document the channel comes back to that gets edited rather than buried in history.
Edit the content of a canvas — change or add text in a specific place.
List the bookmarks pinned to the top of this conversation — the links everyone here sees above the message history. Each one comes back with a bookmark_id, its title and its URL. Use it when someone asks what is bookmarked, when they refer to a link that sounds like it lives up there ('the runbook we pinned'), or before removing one — a bookmark_id is opaque and a listing is the only place to get a real one.
Output schemas completely undocumented. We can infer what tools return from descriptions (e.g., list_bookmarks returns bookmark_id, title, URL), but there is no structured output schema definition in the code. This violates pattern:tool-chain and pattern:response-shaper, agents cannot compose tools reliably without knowing return types.
Input parameter types are present in JSON Schema but lack formal type constraints in descriptions. Parameters like 'title', 'url', 'canvas_id', 'text', 'destination' have descriptions but no mention of format (length, pattern, enum alternatives). E.g., 'title' in add_bookmark should state 'string, 1-100 characters'; 'url' should state 'valid HTTP/HTTPS URL'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
List the canvases in this channel — the documents the channel comes back to.
Read the content of a canvas — see what is in it without changing anything.
Remove a bookmark from the top of this conversation — only when someone here asks you to remove that specific one. It disappears for everyone, and it may be a link somebody else put there, so never tidy the bookmark bar on your own initiative and never remove one merely because it looks stale. If there is any doubt about which bookmark they mean, list them and ask. The bookmark_id must come from list_bookmarks — it is checked against the conversation's live bookmarks before anything is removed, so a remembered or guessed id is refused.
Change the purpose of this channel — the longer description of what it is for.
Change the topic of this channel — the one-line description everyone sees.
Choose where this reply goes: in the thread (where only people following it see it) or at the top of the channel (where everyone reading the room sees it).
No error recovery guidance. Tools like remove_bookmark and edit_canvas are marked IRREVERSIBLE and WRITE respectively, but descriptions do not explain what happens if the resource is not found, if permissions are insufficient, or if the operation fails mid-way. Pattern:recovery-guide requires actionable error messages.
Irreversible operations lack confirmation or dry-run pattern. remove_bookmark and edit_canvas are destructive but the descriptions do not mention a confirmation step or preview mode. This violates pattern:confirmation-request, increasing risk of accidental data loss.
Missing chaining IDs in inferred return values. list_bookmarks and list_canvases likely return lists but no cursor/pagination info is documented. If results are large, agents cannot paginate. Pattern:paginated-result requires explicit next_cursor or offset/limit support.
Parameter 'find_text' in edit_canvas is required only for 'replace' operation but the schema marks it as required unconditionally. Description hints at this dependency ('required for replace operation') but JSON Schema does not enforce conditional requirements, risking invalid calls.
No security scope declarations. Tools like set_channel_topic and set_channel_purpose modify channel metadata but do not specify what permissions (e.g., 'write:channel') they require. Pattern:scope-declaration requires explicit permission declarations for audit and least-privilege configuration.