Skip to main content
AI SRE is available to accounts on an On-call Pro or higher subscription, with no application needed. Starting September 16, 2026, 08:00 Beijing time, it must be activated in the console before use and is billed on actual usage; see billing terms.

​
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 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 for details.

​
Installing MCP Servers from the Marketplace

Go to Customize → Plugins → Overview to see Flashduty’s curated catalog of third-party MCP templates. The catalog is grouped into category tabs (All / Observability / Cloud & Infrastructure / Database & Middleware / Code & Collaboration / Skill), and the search box in the top-right corner filters it by name or description. The Recommended block above the catalog (“Recommended from your alert sources and common usage. Once connected, AI SRE can use them during investigations.”) picks the templates that match the alert integrations already configured in your account (ranked by alert count over the last 30 days), then fills in the picks promoted for your current locale, showing at most 3. Installed templates, templates that need a Runner, and templates you may not install never appear here.
1

Find the template to connect

Each catalog row shows the template name and description; when MCP / App / Skill rows are mixed on the same screen, the row also carries a kind tag. An uninstalled row has a round + button on its right: clicking + or clicking the row itself opens the Connect dialog. When a template needs a self-hosted Runner and the account has no Runner available, the row’s tag reads Requires a self-hosted runner; for a template you may not install, the row shows no + and is not clickable.
2

Review the template and fill in the connection parameters

The dialog first shows the template’s details: the vendor (“Official Datadog · MCP” or “Community · MCP”), a link to its official docs, its description, and a set of “Ask things like this once connected” example questions. Then come the connection parameters the template declares — URL / endpoint placeholders and environment variables. Shared fields (shared account-wide under service authorization) are labelled “Shared by the whole account.”; in Member authorization (key) mode there is also a “Your API token” field (a password input) labelled “Only for your own use — other members fill in their own the first time they use it.”, with a “How to get one” docs link beside it.
3

Pick an execution environment and submit

Choose the execution environment this connection should be made from — “Connects in the session’s own environment by default.”; for a template that needs a self-hosted Runner, the hint reads “If 〈name〉 is only reachable on your internal network, pick a self-hosted Runner on that network.” The primary button is Connect; for a Member authorization (OAuth) template it reads “Authorize 〈name〉” and creates the connector first, then opens the browser authorization window (OAuth discovery, Dynamic Client Registration, and token exchange all run from the chosen environment).
4

Confirm the result

On submit, the system creates the connector and runs one connection test against it. On success the dialog shows “〈name〉 connected” plus the example questions: click Done to close it, or click an example question to open a new chat with that question prefilled (it is not sent automatically). On failure it shows “The connection test failed” with the raw error: click Retry to re-run the test; for a template that needs a Runner, a non-cloud environment also offers a “Let AI SRE install it on the Runner” entry, which opens a new chat that carries no token and asks the agent to install the missing command-line tools (npx’s Node.js, uvx’s uv) on the self-hosted Runner.
The dialog creates the connector on the first submit only. After that its connection parameters are locked, and it shows “This connector already exists, created from the values you first submitted. To change them, edit it under Plugins → MCP.” When the name collides with a connector that already exists, the dialog no longer echoes the backend error and instead shows “This account already has a connector named “〈name〉”. If that is the one you want, finish authorizing it under Plugins → MCP; otherwise an account owner or admin has to rename or delete it there first, then connect again.”
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. Marketplace-installed MCP servers are fixed to Shared scope (account-level, team_id is 0) and available to all members of the account; no team owner can be chosen at install time, and the same template can only produce one instance per account.
A template that requires a Runner (the requires_runner flag in its details) can only be used in an environment where you have deployed a BYOC Runner; cloud Sandboxes do not support it. requires_runner is independent of transport, and today’s 50-template catalog contains both kinds: 23 HTTP Streaming templates that need no Runner, and 27 stdio templates that do — including Alibaba Cloud OpenAPI, Alibaba Cloud Observability, Nightingale (n9e), Gitee, GreptimeDB, Prometheus, Grafana (Self-Hosted), Kafka (Confluent), AWS, ClickHouse, MySQL, PostgreSQL, Alibaba Cloud RDS, Redis, and MongoDB. Those stdio templates are launched locally on each environment via uvx / npx, and a cloud Sandbox cannot launch local subprocesses; confirm your account has a working BYOC Runner configured before installing. See Environments (BYOC).

​
Systems only Monitors can query

The catalog also contains a class of rows for systems only Monitors can query (currently Loki, VictoriaLogs, and Oracle): they appear under their category (Observability / Database), and when MCP / App / Skill rows are mixed on the same screen they carry a Monitors kind tag. They are not connectors you can onboard from the marketplace — they are entry points meaning “once you add a datasource in Monitors, AI SRE can query this system” — so they never appear in the Recommended block above (that block lists connectable templates). Clicking such a row (or its +, which opens the same panel) opens a panel with no Connect button, showing only:
  • The account’s datasources of that type and their status, e.g. “N connected · runs through the alert engine — no URL, token or Runner needed”; with none yet it reads “No 〈type〉 datasource yet · add one in Monitors and you can query it, no Runner needed”. The row’s + appears only while the account has no datasource of that type and you have permission to add one; otherwise that slot shows “N connected” or “Added by a Monitors admin”.
  • When datasources of that type exist, the primary button is Try it in chat: it opens a new session prefilled with a question against your datasource (it is not sent automatically).
  • With none yet, it offers Add more in Monitors →, opening Monitors → Datasources → Add in a new tab (the type preselected); a member without add permission only sees “A Monitors admin adds it and this updates automatically” and is not offered that action.
Some MCP templates support both routes — a direct MCP connector and the Monitors one (for example Prometheus, MySQL, PostgreSQL, ClickHouse, Elasticsearch, SLS). Those rows are tagged MCP · Monitors and their dialog adds an “Access method” choice between the two.
Row names share a namespace with template names: if a system already has a template of the same name, only the template row is shown (the template row is the one carrying connection parameters). On a private deployment without the Monitors module, these rows are not listed and a template’s dialog offers no Monitors route — the list API returns monit_available: false and the console hides the related affordances based on it.

​
Adding an MCP Server

Go to Customize → Plugins → MCP. The list page has two entries in the top-right corner:
  • Add MCP: opens a form for defining an MCP server by hand (its fields are listed under “Basic Fields” below).
  • Add in chat: opens a new AI SRE session with this prompt prefilled — “I want to add an MCP server. First ask whether I want to connect my own service or install an existing one. If it is an existing one, ask which system I want to connect. If the plugin catalog has it, install it; if not, search the web and show me a few to pick from. Install the one I choose.” The agent first asks whether you want to connect your own service or install an existing one; for an existing one it checks the plugin catalog first and only searches the web for candidates when the catalog has none, then completes the connection once you pick (nothing is sent automatically — you can edit the prompt first). The button appears only when there is an unambiguous scope to write into: always when you can author at account scope, otherwise when the current scope filter selects exactly one team you belong to (or you belong to exactly one team).

​
Basic Fields

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

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).
stdio server commands run on the machine where the Runner is deployed, not on the machine of the person who configured them. Shared configuration must be portable: do not write personal machine paths into commands or arguments (e.g., /Users/your-name/..., /home/your-name/...), and make sure the executing environment has the runtime the command needs (uv / uvx / node / npx). A missing runtime makes the server fail to connect.
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 authorization modes that determine how credentials are provided to the server:
All sessions call with the same service identity. 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.Credentials are encrypted at rest: on save, any entry whose key name contains KEY, SECRET, TOKEN, PASSWORD, PASSWD, CREDENTIAL, or AUTHORIZATION (case-insensitive) has its value encrypted before storage and returned masked on read; in addition, an entry whose key name has a whole non-alphanumeric-delimited segment equal to PWD or PASS is treated the same way — REDIS_PWD, db-pass and a bare PWD all qualify, while BYPASS and COMPASS (which only contain that text inside a segment) do not. Entries matching none of these rules are stored as-is, so put credentials under a recognizable key name (such as Authorization, X-API-Key, or GITHUB_TOKEN).A service authorization means any session in the account can call the system as that service identity. If it exposes members’ personal data or allows high-risk writes, prefer “Member authorization (key)” or “Member authorization (OAuth)”.
For “Member authorization (key)” and “Member authorization (OAuth)”, if credentials are missing the agent’s tool call is paused and a credential entry or authorization dialog is shown to the current member; execution resumes once credentials are supplied. In service authorization mode, no credentials are requested from members.

​
MCP Server Authorization (Settings)

Member authorization credentials — both key and OAuth — are isolated per member, 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-member credential. Auth-status chip in the list: the MCP list’s Member authorization column shows a per-viewer auth-status chip for each MCP server, reflecting the current viewer’s credential. The wording depends on the authorization mode — since a saved member key is never verified for validity, it deliberately avoids the word “Connected”:
  • Member authorization (OAuth): ● Connected (a valid credential is saved) / ○ Disconnected (no credential provided yet).
  • Member authorization (key): ● Saved (a key is saved) / ○ Not set (no key provided yet).
  • Shared across both modes: ⚠ Expired (the credential has expired — OAuth token lapsed — and needs re-authorization).
MCP servers using service authorization have no per-member authorization step and render a dash (”—”). For a server that needs your personal credential, open the Credential dialog from its authorization entry in the list. It manages only your credential and never changes the server endpoint, authorization mode, or scope. Actions in the Credential dialog: the dialog offers actions based on its authorization mode and your current credential state:
  • Member authorization (OAuth): first choose an execution environment, then click Authorize (when disconnected) / Reauthorize (when connected or expired). Choose a Cloud Sandbox or an online BYOC Runner; Auto is not available. OAuth discovery, Dynamic Client Registration, token exchange, and later refreshes all run from that environment. On each open, the dialog prefers the last successful environment if it is still online, then an online runner bound to the connector, and finally the Cloud Sandbox. For an OAuth service reachable only on a private network, choose a BYOC Runner that can reach it. A browser popup then opens the authorization window (initiated via /safari/credentials/oauth/initiate, which returns an authorize URL opened in the popup).
  • Member authorization (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 postMessages 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), scope (Shared or team name), transport, an enabled toggle, and an actions column — the list only contains MCP servers you have added to the account; the built-in Flashduty MCP server is injected by the runtime and does not appear in this list, see “Inspection” below. The scope filter bar at the top lets you switch between All / Shared / Team views, and the search box to its right filters the list by keywords in the name, description, transport, or URL.
Toggle the switch in the list. Only enabled servers are available to the agent; disabled servers are invisible to agents and cannot be called.A disabled connector (any status other than enabled) is not reported as connected by the connect entry point: opening its Connect dialog shows “Connector disabled” and “This connector is disabled, so AI SRE can’t use it. An account owner or admin has to re-enable it under Plugins → MCP.”, with an Open Plugins → MCP button that jumps to that connector’s row. An account owner or admin re-enables it there with the Enable toggle. Disabled connectors also drop out of the Enabled strip on Plugins → Overview.
Click the edit button (or click the row) to open the form. You can modify the name, transport, description, endpoint/command, authorization mode, and scope. If you do not have edit permission, the form opens in read-only mode with an explanation.
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.
Reading Flashduty incidents, alerts, and other data is a built-in agent capability: the Flashduty MCP server is injected directly into the agent at the start of every session by the runtime, bypassing this page’s MCP server list API — it does not appear in the server list above, and there is nothing to configure, enable, or view here for it. This capability is maintained by the platform and is available to every account by default.

​
Cross-environment connectors

An MCP server can be bound to execution environments other than the current session’s own. That session cannot call it directly — execution environments do not share a network, and a tool call is always made from the session’s own environment. But the agent does not conclude the connector is absent:
  • The agent knows about it from the start: at session start the agent sees the connectors that are connected but bound to another execution environment — their names, what they do, and which execution environments they run in. The same connector can resolve to different names in different environments, so directory entries carry a team annotation to keep them distinguishable.
  • A search states where it can run: when a search matches such a connector, the result carries the environments it runs in.
  • Asking for it by name is not answered with “not found”: when the agent looks a connector up by name, it gets an explanation that the connector is connected but bound to another execution environment, plus how to use it — rather than being told the account has no such thing.
  • The way to use it is to dispatch a subagent into that environment: the agent hands the work to a subagent running in the target execution environment (agent_dispatch’s environment argument — see Agent), and that subagent discovers and calls the server’s tools on its own side, then brings the results back into the conversation.
  • Only environments it can actually dispatch to are listed: the targets are account-scope Runners plus the Runners of the team the current session is bound to, and online ones (plus the bound cloud environment). Environments that are offline, never connected, deleted, or scoped to a team this session cannot dispatch to are annotated with the reason, and the agent says so plainly instead of pretending the call is possible.
  • Only the conversation’s main session sees this directory: a dispatched subagent has no dispatch capability of its own and reports only the connectors it can call directly in its own environment; when another environment is needed, the subagent reports back to its parent.
Conversely, to make a connector directly usable here, add the current environment to that server’s Execution Environment list (provided the server is reachable from this session). See Environments (BYOC) for how the environments themselves differ.

​
Scope

MCP shares the same two-level scope model as other resources (Skills, Knowledge, Agents, Environments), divided into Shared scope and team scope: Edit permissions: team-level MCP servers can be acted on only by members of that team — organization admins must join the team first; Shared-scope MCP servers can be acted on only by the account owner or admins. 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; Shared-scope creation is limited to the account owner or admins. Marketplace installs are the exception: they are fixed to Shared scope and started by the installer, and any account member can install an ordinary template (no owner/admin permission required). One class of template is the exception to that exception: when a template in a member authorization mode (key or OAuth) also asks for a free-form address / host parameter, the installer would effectively decide where other members’ credentials are sent — so, to keep other members’ credentials from flowing to a host the installer chose, installing and connecting that template is limited to the account owner or admins. A regular member sees no + on that row (and cannot click it), and opening its Connect dialog directly says “You don’t have permission to install this. Ask your account owner or an admin.” 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. However, Marketplace-installed MCP servers cannot be reassigned to a team — their scope is shown as a fixed Shared value in the edit form. A small number of legacy team-scoped Marketplace rows from earlier versions can still be changed back to Shared scope; the reverse is not allowed. Promoting to Shared scope carries the same gate as Shared-scope creation: only the account owner or admins can do it — a regular member is denied even for servers belonging to their own team, and the prompt now reads “ask an admin to make it shared” instead of naming the owning team. Runtime visibility: At session start, the agent is offered only Shared-scope 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.

Skills

Skills call MCP-provided tools inside SKILL.md using the mcp:server/tool notation.

Agent

Agents share the same authorization modes and scope model as MCP.

BYOC

stdio MCP servers must run on a BYOC Runner; learn the difference between cloud Sandbox and self-hosted environments.

Console

Observe how agents inspect and invoke MCP tools during a session.

Flashduty MCP Server (Developer)

The opposite direction: the official MCP service for connecting Flashduty into third-party AI clients.