Slack MCP draft message plus Sume: post a generated clip after review

Yes: an agent that has both Slack's MCP server and Sume's hosted MCP server connected can generate a clip on Sume and leave it in Slack as a draft message for a person to send. Slack's documentation lists draft and schedule tools next to send, so the review step can be built from the tools themselves, with no custom approval service.

Slack's side comes from its Slack MCP server documentation, read on 2026-10-11. Sume's side comes from MCP tools and gates, the core workflow and Jobs and results. The two servers do not connect to each other; the client holds both, and the agent moves a link between them.

What does the Slack MCP server require?

The page gives the endpoint as https://mcp.slack.com/mcp, JSON-RPC 2.0 over streamable HTTP. Sign-in is confidential OAuth 2.0 with user tokens, and the page states that only directory-published apps or internal apps may use MCP, with a registered app of fixed ID, workspace admin approval, and no unlisted apps. Dynamic client registration is not supported. It names Claude.ai, Claude Code, Perplexity and Cursor as supported clients.

None of that touches Sume. Slack's rules decide whether your client can talk to Slack; Sume's rules decide whether it can talk to Sume. Sume's own sign-in is separate, and an agent can have one connection healthy and the other broken.

Which URL should the draft contain?

Use the durable one. Sume's core workflow page says completed jobs can include public artifacts under https://media.sume.com. That is the link to put in a Slack draft. Do not use the URL from assets_download_url: Sume's tool description calls it a short-lived URL, says it is sensitive, and tells agents not to paste it into chat reports. A signed link in a channel would expire, and it would be visible to everyone with channel access.

Read the artifact from jobs_result after jobs_wait reports the job complete. Each jobs_wait call holds up to 55 seconds, so a longer render is several calls on the same job id, never a second create.

How do the two tool sets divide the work?

The table shows who does what in the flow. The Slack column is limited to what the Slack page lists.

What can go wrong between the two?

Three failures are common in a two-server setup. The first is a scope mismatch: if Sume was connected with read-only OAuth, generate_video returns insufficient_scope, and an agent may then offer to describe the clip instead of making it. Check tools_list before you blame Slack. The second is a lost wait: a jobs_wait that times out at the edge is a transport failure, not a job outcome, so call it again on the same ids. The third is a pasted secret: never put an API key, an OAuth token or a signed URL into a Slack message or a draft.

Sume's safe-automation page lists request ids, job ids and high-level status as safe to log, and keys, signed URLs and raw private media URLs as unsafe. A draft that carries only the public media link and a job id follows that list.

Where should the approvals sit?

Put the human check on the Slack side, after the spend, and put the cost check on the Sume side, before it. The dry run tells the agent what the clip would cost; the optional max_spend_usd is enforced only when you provide it; and Sume says there is no mcp:paid scope, so the wallet and admission are the spend gate. Slack's draft tool then keeps a clip from reaching a channel until someone reads it.

Slack's page says rate limits vary by tool, from Tier 2 (20 or more per minute) to Tier 4 (100 or more per minute), with special limits for search and send. A single draft per clip stays far below any of them. If the agent posts in bulk, make that a separate decision, and keep each Sume create on its own idempotency key so a retry cannot generate the clip twice.