The slack_read_thread tool requires its parameter to be named message_ts. Elsewhere in the Slack ecosystem the same value is typically called thread_ts: it's the name in Slack's Web API, and it also appears in the permalinks returned by the search tools (?thread_ts=<ts>). We've observed LLM agents occasionally calling slack_read_thread with thread_ts instead of message_ts (likely pattern-matching from prior search output), and the server rejects those calls.
Reproduction:
- Call
slack_search_public_and_private with any query. The result permalinks contain ?thread_ts=<ts>.
- Ask an LLM agent to read the thread for one of the results.
- The agent calls
slack_read_thread { channel_id, thread_ts: <ts> }.
- The server returns
initialization_failed: Missing value for parameter `message_ts` .
- The agent retries with
message_ts and the call succeeds.
Expected:
Either accept thread_ts as an alias for message_ts, or rename message_ts to thread_ts so the input matches the Slack API and the MCP's own response data.
Actual:
First call fails. Each occurrence costs roughly 750 ms plus the model tokens to read the error message and retry.
Note:
We've seen this on claude-opus-4-8 more than once. Since thread_ts is the canonical name in Slack's docs and the parameter that appears in the MCP's own response permalinks, any LLM client trained on Slack documentation is likely to default to it. A one-line server-side change to accept either name would fix it.
The
slack_read_threadtool requires its parameter to be namedmessage_ts. Elsewhere in the Slack ecosystem the same value is typically calledthread_ts: it's the name in Slack's Web API, and it also appears in the permalinks returned by the search tools (?thread_ts=<ts>). We've observed LLM agents occasionally callingslack_read_threadwiththread_tsinstead ofmessage_ts(likely pattern-matching from prior search output), and the server rejects those calls.Reproduction:
slack_search_public_and_privatewith any query. The result permalinks contain?thread_ts=<ts>.slack_read_thread { channel_id, thread_ts: <ts> }.initialization_failed: Missing value for parameter `message_ts`.message_tsand the call succeeds.Expected:
Either accept
thread_tsas an alias formessage_ts, or renamemessage_tstothread_tsso the input matches the Slack API and the MCP's own response data.Actual:
First call fails. Each occurrence costs roughly
750 msplus the model tokens to read the error message and retry.Note:
We've seen this on
claude-opus-4-8more than once. Sincethread_tsis the canonical name in Slack's docs and the parameter that appears in the MCP's own response permalinks, any LLM client trained on Slack documentation is likely to default to it. A one-line server-side change to accept either name would fix it.