> ## Documentation Index > Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt > Use this file to discover all available pages before exploring further. # MCP (External Tool Connections) > Use the Model Context Protocol (MCP) to connect AI SRE agents to external tools and data sources — such as GitHub, Slack, Kubernetes, and observability platforms. Configure MCP servers, authentication, and scope in the console; agents will call their tools on demand during a session. **Private beta**: AI SRE is currently in private beta. Pro or higher accounts can apply for free beta access through the [AI SRE private beta application form](https://c9xudyniiq.feishu.cn/share/base/form/shrcn0ngCfdoygiaHnAT80BfZiH); after approval, Flashduty will add your account to the whitelist. Features and the UI may change during the beta. ## Overview *** **MCP** (Model Context Protocol) lets AI SRE agents connect to external tools and data sources. Each **MCP server** is a standardized endpoint that exposes a set of tools (functions) — for example, querying GitHub issues, sending Slack messages, reading Kubernetes resources, or retrieving metrics from an observability platform. Once you configure and enable an MCP server in the console, agents will **autonomously decide** when they need an external capability during incident investigation and call the corresponding tool directly — no manual data-shuttling required. This page covers the **"MCP" section inside the AI SRE console** — that is, **third-party MCP servers that agents call** (you bring external tools in for agents to use). This is **different** from the [Flashduty MCP Server](/en/developer/mcp-server) in the developer docs: that is **Flashduty's own outbound MCP service**, which lets you connect **Flashduty's capabilities into third-party AI clients** (such as Claude or Cursor). One direction is "agents calling external services"; the other is "external clients calling Flashduty" — they are opposite flows, not the same thing. ## What Is MCP *** **MCP** (Model Context Protocol) is an open protocol that describes in a uniform way "what tools a server exposes, what parameters each tool accepts, and what it returns." Think of it as the "USB port" of the AI agent world — any MCP-compliant server can be discovered and called plug-and-play by an agent, with no per-system adapter code required. In AI SRE, MCP extends an agent's capability from "built-in tools" to "any external system": * You add an MCP server in the console (declaring its endpoint, transport, and authentication). * At session start, enabled servers visible in the current scope become available to the agent. * When needed, the agent discovers the tools that server provides and calls them directly. **MCP vs. Skills**: MCP provides **the ability to connect external tools**; a Skill provides **the methodology for orchestrating those tools to accomplish a class of tasks**. A Skill can declare which MCP server tool it needs inside `SKILL.md` using `mcp:server/tool` notation. See [Skills](/en/ai-sre/skills) for details. ## Installing MCP Servers from the Marketplace *** Go to **Plugins → MCP** and click **Browse Marketplace** to open the **MCP Directory**, where you can browse Flashduty's curated selection of third-party MCP server templates. Click **Browse Marketplace** on the MCP list page to open a directory dialog that displays all available MCP server templates in a card grid. Each card shows the MCP server name, author, description, and tags. Click any MCP server card to open the detail view, which shows the full description, transport, authentication mode, whether a BYOC Runner is required, the vendor, connection parameter documentation, and a link to the vendor's official docs. Cards for already-installed MCP servers display a gear icon; clicking it takes you directly to that server's edit form. For MCP servers not yet installed, click the **Install** button on the card. The system opens a new AI SRE session and injects the server's template metadata. The agent then guides you through entering the endpoint URL, completing credential authorization, and calls `tool_search` (probing the server's tools by name) to verify connectivity — the entire install flow happens **inside the conversation**, not through a one-click write to the database. Once the agent verifies connectivity, it writes the MCP server into the account via the `/safari/mcp/server/create` endpoint. The server then appears in the MCP list and is marked as "Installed" on the catalog card. The marketplace directory is **browse-only** — there is no one-click install endpoint. This is intentional: installing an MCP server must involve credential entry and connectivity verification. Skipping those steps would leave dead configurations in the account that can never actually connect. Conversational install ensures every MCP server has been validated by a real agent invocation before it is considered ready. Installed MCP servers record a `source_template_name` field that points back to the originating template, making it easy to trace the server's provenance later. If the same template is installed more than once (for example, into different team scopes), each installation creates an independent MCP server instance. MCP servers marked **requires Runner** (shown by the `requires_runner` flag in the detail view; `requires_runner` is independent of transport, and the entire current curated catalog is HTTP Streaming and needs no Runner) can only be used in environments where you have a BYOC Runner deployed; cloud Sandboxes do not support them. Before installing, confirm your account has a working BYOC Runner configured. See [Environments (BYOC)](/en/ai-sre/environments). ## Adding an MCP Server *** Go to **Plugins → MCP**, click **Add Server** in the top-right corner, and fill in the form to define an MCP server. ### Basic Fields | Field | Type | Required | Description | | ----------- | -------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | string | Yes | The server name, used as the identifier when agents call it (e.g., `sqlite-explorer` in `mcp:sqlite-explorer/query`). Must start with a letter; may only contain letters, digits, `-`, and `_`; length 1–255. **Case-insensitive and unique** within an account; cannot duplicate a built-in server name. | | Transport | enum | Yes | How the agent communicates with the server. See "Transport" below. | | Scope | Account / Team | Yes | The scope of this MCP server: **Account** (visible account-wide) or a specific **Team** (visible only to members of that team). See "Scope" below. | | Description | string | Yes | Describes what this server does, for identification in the list. | Each MCP server also has an **AI description**: after an agent first lists a server's tools, the system automatically generates a capability summary from the tool list and displays it in the console. This summary refreshes automatically as the tool set changes — no manual maintenance needed. ### Transport | Transport | Use Case | Required Fields | | ---------------------------- | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | | HTTP Streaming (recommended) | Remote MCP server accessed via an HTTP endpoint | URL (endpoint), optional Headers (JSON); HTTPS endpoints can optionally skip TLS certificate verification | | SSE (standalone, legacy) | Legacy remote servers that only support Server-Sent Events | URL (endpoint), optional Headers (JSON); HTTPS endpoints can optionally skip TLS certificate verification | | stdio (local command) | MCP server launched as a local subprocess on the machine where the Runner runs | Command, arguments (one per line), environment variables (JSON) | **stdio is only available for BYOC environments** (Runner deployed on your own machine). Cloud Sandboxes cannot launch local subprocesses. If you are using a cloud environment, use **HTTP Streaming** or **SSE** instead, and ensure the MCP server is reachable from the Sandbox network. For differences between environments, see [Environments (BYOC)](/en/ai-sre/environments). There is a default timeout for both connection and tool calls: 10 seconds for connection, 60 seconds for tool invocation. Use "Skip TLS certificate verification" only when the remote HTTPS MCP server uses a self-signed certificate and the network is controlled. After you enable it, the agent execution environment skips certificate-chain and hostname verification when connecting to that server. Do not use it for untrusted public endpoints. ### Authentication MCP servers support three **authentication modes** that determine how credentials are provided to the server: All users share the same credentials. Credentials are written directly into the server configuration — for HTTP/SSE transport, in the **Headers** (JSON) (e.g., `{ "Authorization": "Bearer xxx" }`); for stdio transport, in the **environment variables** (JSON) (e.g., `{ "API_KEY": "xxx" }`). Suitable for internal systems accessed with account-level service tokens. Each user provides their own key the **first time** they invoke a tool on this server. Keys are encrypted and stored at the account level, isolated per user. Selecting this mode requires filling in a **Key Schema**: | Field | Required | Description | | ----------- | -------- | ----------------------------------------------------------------------------------------- | | Header Name | Yes | The HTTP header into which the credential is injected in MCP requests (e.g., `X-Api-Key`) | | Placeholder | No | Placeholder hint for the input field (e.g., `sk-...`) | | Help Link | No | Link to documentation explaining how to obtain the key | Suitable for third-party SaaS where each engineer uses their own API key (e.g., a personal GitHub token). Each user authorizes individually via **OAuth 2.1**. An authorization window pops up automatically the first time a tool on this server is invoked. Server discovery and Dynamic Client Registration (DCR) are performed as needed; tokens are stored per user and refreshed automatically near expiry. Suitable for services that support OAuth. For "Per-User API Key" and "Per-User OAuth", if credentials are missing the agent's tool call is paused and a credential entry or authorization dialog is shown to the current user; execution resumes once credentials are supplied. In Shared mode, no credentials are requested from the user. ### MCP Server Authorization (Settings) Per-User API Key and per-user OAuth credentials are isolated **per user**, so besides the inline "prompted on demand during a conversation" path above, you can also **manage your own authorization** for an MCP server directly **in settings** — both paths write to the **same** per-user credential. **Auth-status chip in the list**: the MCP list shows a per-viewer auth-status chip for each MCP server, reflecting the **current viewer's** credential: * **● Connected**: you have a valid credential saved for this MCP server. * **○ Disconnected**: no credential provided yet. * **⚠ Expired**: the credential has expired (OAuth token lapsed) and needs re-authorization. Shared-mode MCP servers have no per-user authorization step and render a dash ("—"). The chip is read-only; all authorization actions live in the MCP server's edit form. **Actions in the edit form**: open an MCP server's edit form, and the **Authorization** section offers actions based on its authentication mode and your current credential state: * **Per-User OAuth**: click **Authorize** (when disconnected) / **Reauthorize** (when connected or expired). A browser popup opens the authorization window (initiated via `/safari/credentials/oauth/initiate`, which returns an authorize URL opened in the popup). * **Per-User API Key**: click **Enter Key** (when disconnected) / **Update Key** (when connected) to open the secret-entry modal, which submits to `/safari/credentials/secret`. * **Revoke**: when a credential exists, click **Revoke** (via `/safari/credentials/revoke`) to delete your saved credential; the status returns to Disconnected. OAuth authorization completes through a browser **bounce page** at `/oauth-callback`: the authorization server calls back to fc-safari, which then 302-redirects to the bounce page; the page `postMessage`s the result to the window that initiated the flow (the settings page or the chat page) and closes itself automatically. No manual token copy-pasting is required. ## Management & Inspection *** The MCP list displays each server's **name** (including its AI description; built-in servers are labeled with a "Built-in" badge), **scope** (account or team name), **transport**, an **enabled** toggle, and an **actions** column. The scope filter bar at the top lets you switch between All / Account / Team views. Toggle the switch in the list. Only **enabled** servers are available to the agent; disabled servers are invisible to agents and cannot be called. Built-in servers are **always enabled** and their toggles cannot be changed. Click the edit button (or click the row) to open the form. You can modify the name, transport, description, endpoint/command, authentication mode, and scope. If you do not have edit permission, the form opens in **read-only** mode with an explanation; built-in servers are likewise read-only. Removes the MCP server from the current scope. **Agents that depend on it will no longer be able to access its tools**, and active sessions currently using it will fail. A confirmation prompt is shown before deletion. ### Inspection: Viewing the Tools a Server Exposes The tools an MCP server exposes are discovered **during a session** by agents on demand — not displayed statically in the console. This is because the same MCP server may have different reachability and tool sets across different environments (Runners); connection state and tool count are per-environment properties, not global ones. To confirm which tools a given MCP server actually exposes in a particular environment, the most direct way is to ask the agent in **Chat** to list that server's tools — it will show the tools and how to use each one. See [Conversations](/en/ai-sre/sessions). Every account comes pre-configured with a **built-in Flashduty MCP server** (labeled "Built-in" in the list, read-only, always enabled), which lets agents read Flashduty incidents, alerts, and other data directly. It is maintained by the platform and requires no configuration on your part. ## Scope *** MCP shares the same **two-level scope** model as other resources (Skills, Knowledge Packs, Agents, Environments), divided into account level and team level: | Scope | Visibility | | ------------- | ------------------------------------- | | Account-level | Visible to all members of the account | | Team-level | Visible only to members of that team | **Edit permissions**: Account owners or account admins can edit any MCP server; team members can edit team-level MCP servers that belong to **their team**. There is no creator-retains-rights exception. When you lack edit permission, the toggle and action buttons for that row appear as **read-only**. **Create and reassign**: to create a new team-level MCP server, you must belong to the target team; account-level creation is limited to the account owner or admins. When editing an existing MCP server, the account owner or admins can move it to any team to recover resources left behind by empty teams or departed members; regular members can move it only to teams they belong to. **Runtime visibility**: At session start, the agent is offered only **account-level** MCP servers and servers belonging to the **team bound to the current session**. Once the agent reads a team's knowledge during an investigation, that team's MCP servers and Skills are mounted into the session on demand. **The account is the only security boundary at runtime; the team is an ownership and editing tag only.** ## Related Pages *** Skills call MCP-provided tools inside SKILL.md using the `mcp:server/tool` notation. Agents share the same authentication modes and scope model as MCP. stdio MCP servers must run on a BYOC Runner; learn the difference between cloud Sandbox and self-hosted environments. Observe how agents inspect and invoke MCP tools during a session. The opposite direction: the official MCP service for connecting Flashduty into third-party AI clients.