capture-and-slack-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SLACK_BOT_TOKEN | Yes | Slack bot token (xoxb-...). Required to post. | |
| CAPTURE_WINDOW_TITLE | No | Default window title substring for live captures. | Clonify |
| SLACK_DEFAULT_CHANNEL | No | Default destination: U... (DM), C... (channel), or D... (DM channel). | |
| CAPTURE_SLACK_MAX_FILE_MB | No | Reject larger image files before uploading. | 25 |
| CAPTURE_SLACK_SCRATCH_DIR | No | Where captured PNGs are written. | <tmp>/capture_and_slack_mcp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_to_slackA | Post one or more existing image files to Slack as a review. Posts a root anchor message (a
Block Kit task card when title/status/checks/links are given) and threads the image(s) beneath
it. Returns a JSON status including |
| capture_window_and_postA | Screenshot the running app window (X11/KDE) and post it to Slack as a review. Use only when no offscreen render exists; otherwise prefer send_to_slack with a repro-rendered PNG. |
| capture_windowA | Capture a screenshot WITHOUT posting, and return it for inspection. Compose with send_to_slack: look at the image, then post the returned path if it's the right frame. No Slack call, so no token/scopes are needed. |
| wait_for_reviewA | Block until the human reacts (π/π/π/βοΈ) or replies in the review thread, or until timeout. Returns a JSON verdict: status is approved / rejected / changes / seen, or 'still_awaiting' on timeout (with a hint to call again). Pair with send_to_slack's review_id. |
| check_reviewA | Non-blocking: read the current review verdict once and return immediately (status approved / rejected / changes / seen / still_awaiting). Use in your own polling loop; use wait_for_review to block until the human responds. |
| ask_reviewA | Ask the reviewer a follow-up question IN SLACK and wait for their typed answer. Posts the
question into the review thread and pings the channel so an away reviewer (watching Slack, not
your terminal) actually sees it β ALWAYS use this instead of asking in the console. Returns the
answer (status 'answered'), or 'still_awaiting' + |
| wait_for_replyA | Block until the reviewer posts a thread reply AFTER |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a clear, distinct purpose: capture without posting, capture and post, send existing files, ask questions, check status, and two blocking wait variants. No two tools overlap in functionality.
All tool names use snake_case with a consistent verb_noun pattern (ask_review, capture_window, check_review, send_to_slack, wait_for_reply, wait_for_review). The slightly longer 'capture_window_and_post' still follows the same structure and is clear.
With 7 tools, the server is well-scoped for its purpose: capturing screenshots and managing Slack review workflows. Each tool adds necessary functionality without bloat or redundancy.
The tool set covers the main workflow: capture, post, review, follow-up. A minor gap is the lack of a tool to post a regular Slack message without a review, but the core review-focused flow is well-supported.