Skip to main content
Glama
LiusDev

slack-bot-mcp

by LiusDev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Send a Slack message

send_message

Post bot messages to Slack channels, threads, or user DMs, returning the message timestamp so you can reply in-thread or wait for a response.

Instructions

Post a message as the bot to a channel, a thread, or a user's DM. target accepts a channel ID (C…), #channel-name, user ID (U…), @handle, email, or a person's name; users get a direct message. Use context to add small reference details under a divider at the bottom (Jira ticket, comment link, source, IDs). Use blocks only when you need a custom Block Kit layout (header, fields, images, etc.). Returns the message ts, which you can pass to wait_for_reply or use as thread_ts to reply in a thread.

Input Schema

NameRequiredDescriptionDefault
textYesMessage content. When `blocks` is set, this is only the notification/fallback text, so keep it a short summary
blocksNoCustom Slack Block Kit blocks (https://docs.slack.dev/reference/block-kit/blocks), e.g. header, section with fields, image, markdown, context, divider. Replaces the rendered `text`; `context` is still appended. Do not use interactive elements (buttons, menus): this server does not handle clicks.
formatNomarkdown: standard Markdown rendered by Slack. plain: sent as-ismarkdown
targetYesChannel ID, #channel-name, user ID, @handle, email, or name
contextNoSmall grey details shown under a divider at the bottom of the message, joined with ·. Example: [{label:"Jira", value:"VEC-123", url:"https://…"}, {label:"Comment", value:"#4521", url:"https://…"}]
thread_tsNoTimestamp of the parent message, to reply inside that thread
expect_replyNoSet true when the message asks something you need an answer to. The question is saved as pending, so check_replies can find the answer later, even from a new session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag this as a non-read-only, open-world write, so the description's added behavior carries the credit: it posts as the bot, resolves users to DMs, appends `context` under a divider, treats `text` as fallback when `blocks` is set, and explicitly warns that interactive elements are unsupported. Remaining gaps are permission requirements and failure modes (e.g., bot not in channel, ambiguous name resolution).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the core action, then parameter guidance ordered by importance (target, context, blocks), then the return value. Every sentence carries distinct operational content with no restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter write tool with no output schema, the description covers the send target, layout mode, and return value (`ts` usable as `thread_ts` or with wait_for_reply). It omits what failure looks like and any constraints on DMing users the bot has never interacted with, which an agent may need when a send silently fails.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above that by clarifying target resolution semantics (email/name → DM) and giving a usage rule for `blocks` vs `text` that the schema doesn't state. It does not, however, explain precedence among identifier types or ambiguity handling for names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Post a message as the bot to a channel, a thread, or a user's DM.' That single sentence distinguishes it from edit_message, delete_message, and the read-oriented siblings, and the DM-vs-channel outcome is stated explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real selection guidance: users get a DM (not a channel post), `context` is for small reference details, and `blocks` should be used 'only when you need a custom Block Kit layout.' It also points forward to wait_for_reply/thread_ts. It stops short of naming siblings it should not be used instead of (edit_message, delete_message), so no explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools