MCP (Model Context Protocol) is an open standard that lets an AI agent call tools in other systems: query a warehouse, read a Linear issue, update a CRM record. The most useful MCP use cases for teams are the ones that live where people already ask questions, which for many teams is Slack. Below are six workflows that work today with Runbear's managed or custom MCP servers, some with triggers, with the setup for each (as of October 2026).
Anthropic introduced MCP in November 2024. The current specification (version 2026-07-28) defines two standard transports, stdio for local processes and Streamable HTTP for remote servers. A server you add yourself must be reachable over HTTPS, because Runbear runs in the cloud.
6 MCP use cases at a glance
- Data questions in plain English: Snowflake, Metabase, PostHog, or Amplitude
- Async standup digest: Linear or Jira, on a schedule
- Pre-meeting briefs: HubSpot, Salesforce, or Attio plus Granola or Fireflies notes
- Error triage: Sentry plus Linear or Jira
- Webhook alerts with context: any system that can send a webhook, plus Stripe or HubSpot
- Internal tools: your own MCP server, connected by URL
1. Answer data questions in plain English
Problem: People outside the data team wait in a queue for simple numbers, or pull them from a dashboard that does not quite answer the question.
Workflow: Connect a warehouse or analytics server from the Runbear tool catalog, such as Snowflake, Metabase, PostHog, or Amplitude. Anyone in the channel who has access can mention the agent and ask a question. The agent picks the right tool, runs the query, and replies with the number and how it got it.
Setup note: Metabase is offered in two versions in the catalog: one runs as a single service account, and the OAuth version lets each member query under their own Metabase permissions. Snowflake always connects per user, so each person links their own Snowflake account before the agent can query for them. Snowflake also needs a managed MCP server and an OAuth client set up on the Snowflake side first.
2. Post an async standup digest from Linear or Jira
Problem: Daily status meetings take time from every engineer, and the information is already in the issue tracker.
Workflow: Connect Linear or Jira, then add an On Schedule job on the agent's Event Triggers tab, for example weekdays at 9:00 AM in your timezone. The job's prompt asks for issues completed, in progress, and blocked in the last 24 hours. Turn on Notification and pick a Slack channel, and the agent posts the digest there each morning.
GitHub is also available as a managed server, but it is in beta and rolled out per organization, so check the Tools tab before you plan around it.
3. Prepare pre-meeting briefs from the CRM and past calls
Problem: Before a customer call, account managers dig through CRM notes, email, and old call recordings.
Workflow: Connect your CRM (HubSpot, Salesforce, or Attio) and a meeting notes server (Granola or Fireflies). Ask the agent for a brief on the account: recent conversations, open deals, and anything promised on the last call. Because the agent reads live data, the brief reflects the CRM as it is at that moment.
Where the connector offers a choice (Attio, for example), pick Per-User so each rep sees only what their own account can see. Salesforce always connects per user. HubSpot connects with one private app token, so everyone on the agent shares that token's access.
4. Triage errors from Sentry into Linear or Jira
Problem: An alert lands in the incident channel, and someone has to open Sentry, read the error, and copy the details into a ticket.
Workflow: Connect Sentry and your issue tracker. In the incident thread, mention the agent with the Sentry issue link and ask it to summarize the error and open a ticket. The agent reads the issue through the Sentry server and creates the Linear or Jira ticket in the same reply, so the thread ends with a link instead of a to-do.
5. Turn webhooks into Slack alerts with context
Problem: Raw webhook alerts tell you that something happened, not what it means for the customer.
Workflow: Add an HTTP / Webhook trigger and point your system at its URL. Each request runs the agent with your prompt and the request body. A prompt such as "look up this customer in HubSpot and Stripe, then summarize their plan, open deals, and recent payments" turns a bare event into an alert someone can act on. Under How to get alerted, send the result to a Slack channel or DM.
Two details from the trigger docs matter here. The webhook URL is the only credential, so keep it secret. And the caller does not get the agent's reply, so the alert destination is where the result shows up.
6. Connect your internal tools with a custom MCP server
Problem: The system your team asks about most is often internal: an admin API, an inventory service, a pricing calculator.
Workflow: Wrap the API in an MCP server and add it on the Tools tab with Add Custom MCP. Runbear connects over Streamable HTTP and also supports older SSE servers, with OAuth, a static header, or no authentication. A server on your own machine can be exposed through a tunnel such as ngrok or Cloudflare Tunnel. The custom MCP guide covers each field.
Fix tool descriptions before you tune prompts. Short action names, one or two sentences on when to use each tool, and clear error messages make the agent pick the right tool more reliably.
Who the agent acts as
A connected tool authorizes in one of two ways, and some connectors let you pick while others are fixed to one. Per-User means each member links their own account and the agent acts with that member's permissions. Shared means one account serves everyone on the agent, so everyone inherits its access. Where you have the choice, use Per-User for systems where people see different data, and Shared for read-only reference systems everyone may see.
If you need an admin to sign off before an agent can use a new server, tool approvals hold newly connected tools as pending until an Admin approves them. That feature is rolling out gradually: ask support to enable it, then an Admin turns on Require Tool Approval in Settings.
How to set up your first MCP workflow in Slack
- Create an agent and add it to Slack. The Slack integration page walks through the install.
- Open the agent's Tools tab and connect one server from the catalog, choosing Per-User or Shared where the connector offers it.
- Mention the agent in a channel with a question that needs that tool. Once the answers look right, add a trigger so it also runs without being asked.
For an overview of MCP in Slack and individual server pages, see Runbear's Slack MCP integration. If several teams will share one agent, Runbear for teams explains how shared agents and per-user access fit together.
FAQ
What is an MCP use case?
It is a workflow where an AI agent calls a tool through an MCP server to read or change data in another system, such as running a Snowflake query or creating a Linear issue, instead of only answering from what it already knows.
Do I need to host MCP servers myself to use them in Slack?
No. Servers in the managed catalog connect by signing in or pasting a token, with no server for you to run. You only run a server yourself when you add your own through custom MCP.
Can each person use their own account?
For most connectors, yes. Where the connector offers a choice, pick Per-User and each member links their own account, so the agent acts with that member's permissions. Some connectors are always per user (Snowflake, Salesforce, Metabase OAuth), and a few use one shared credential (HubSpot).
Can an MCP workflow run without anyone mentioning the agent?
Yes. Scheduled jobs run on a repeating schedule or once, and event triggers run when a webhook arrives or an event happens in a connected app. Each trigger carries its own prompt and can post its result to Slack or Microsoft Teams.
Get Started
