MCP servers
The MCP servers integration lets you connect any remote Model Context Protocol (MCP) server — Linear, GitHub, GitLab, Notion, Atlassian, Datadog, or a server your own team runs — so the AI assistant can use its tools in the same conversation as your cost, anomaly, insight, and CloudFlow data.
An administrator connects a server once for the organization and decides which of its tools the assistant may use. Each user then authorizes their own account with the third-party service; the assistant acts as that user, with that user's permissions, and every action is attributed to them.
Required permissions
-
DoiT account: Adding, changing, or removing MCP servers requires Manage settings. Any user with access to the AI assistant can authorize or revoke their own account.
-
Third-party service: You need an account in the connected service with permission to grant an application access on your behalf. For GitHub, an organization owner must also install the Cloud Intelligence™ GitHub App; see GitHub.
Connect a server
-
Sign in to the DoiT console, select Data ingestion and integrations > Integrations from the top navigation mega menu.
-
On the MCP servers card, select Manage, then Add server.
-
Select a service (Linear, GitHub, GitLab, Notion, Atlassian, Datadog) or Custom server. The row expands with the server's name, URL and description prefilled; hosted services keep their URL locked, while GitLab and Datadog let you replace the host (for a self-managed instance or a regional site) and keep the path. Custom servers must use
httpsand the Streamable HTTP transport. -
Read and accept the acknowledgement, then select Connect (or Add server for a custom server). The platform checks the URL, contacts the server, and detects how it authenticates:
- A public server is ready immediately and its tools appear in the server details.
- A server that uses OAuth asks you to authorize your own account before its tools can be discovered. Select Authorize to discover tools and complete the sign-in in the window that opens.
- A service that does not register applications automatically, and for which DoiT has no application of its own, shows Client ID and Client secret fields in the expanded row for an OAuth app you registered with that service. Use the callback URL shown under the fields when you register the app.
Servers that require a static API key or another credential the platform cannot obtain on your behalf are not supported yet.
GitHub
The GitHub preset connects the remote GitHub MCP server through DoiT's own Cloud Intelligence™ GitHub App, so you do not register an OAuth app. The preset is read-only and covers repositories, files, commits, issues and pull requests; the assistant cannot create or change anything on GitHub through it.
Before users authorize:
-
A GitHub organization owner installs the Cloud Intelligence™ GitHub App in your organization and selects the repositories it may access. The assistant can only read repositories the app is installed on that the authorizing user can also access.
-
Each user selects Authorize and signs in to GitHub. GitHub asks to confirm the app's access on the user's behalf.
If your organization would rather use its own OAuth app, add a Custom server with the URL https://api.githubcopilot.com/mcp/ and enter that app's client ID and secret; the custom server exposes GitHub's default toolsets, including write tools, which then follow the confirmation rules below.
GitLab
The GitLab preset connects the GitLab MCP server at https://gitlab.com/api/v4/mcp. It registers itself with GitLab automatically and requests only the mcp scope. Users authorize with their GitLab account and the assistant acts with their permissions across projects, issues, merge requests, pipelines and code search.
For a self-managed instance, replace the host in the URL (for example https://gitlab.example.com/api/v4/mcp). The instance must run GitLab 18.6 or later with the MCP server enabled. If your instance administrator has turned off dynamic client registration, register an application in GitLab (Admin > Applications, scope mcp, Confidential cleared, redirect URI as shown in the dialog) and enter its Application ID as the client ID in the server details.
Datadog
The Datadog preset connects the Datadog MCP Server for the US1 site. It registers itself with Datadog automatically and asks for the mcp_all scope; each user signs in with their own Datadog account and the assistant acts with that user's Datadog permissions, so an anomaly or a spend change can be checked against monitors, incidents, deployment events, metrics and logs from the same conversation.
If your organization is on another Datadog site, replace the host in the URL before you connect: mcp.datadoghq.eu (EU), mcp.us3.datadoghq.com, mcp.us5.datadoghq.com, mcp.ap1.datadoghq.com, mcp.ap2.datadoghq.com or mcp.uk1.datadoghq.com. Government sites are not supported by Datadog's MCP server.
The default URL exposes Datadog's core toolset (logs, metrics, traces, dashboards, monitors, incidents, hosts, services, events and notebooks). To add more, append Datadog's toolsets parameter to the URL, for example ?toolsets=core,apm; servers with more than 40 enabled tools are loaded on demand, as described below.
Choose which tools the assistant may use
Open a server's Details to review its tools. They are grouped by what the server declares about them:
| Group | Default | Behavior |
|---|---|---|
| Read-only | Enabled | Runs without asking. |
| Write | Enabled, asks before running | The assistant shows the exact request and waits for you to select Run or Cancel. |
| Destructive | Disabled | Stays off until an administrator enables it. |
Toggle Enabled and Ask before running per tool, or use the switch in a group's header to set every tool in that group at once, then select Save changes. Tools that appear after a refresh are marked New and keep the default for their group until you review them; the server is flagged Tools changed.
The AI assistant attaches at most 40 connected tools per conversation. If a server's enabled tools do not fit, the server list marks it On demand: the assistant still uses it, but first lists its tools and then calls one, which adds a step. Users can attach such a server directly by picking it from Add > Connected tools in the chat, or you can disable tools until everything fits.
Use Refresh tools from the row menu to re-read the server's tool list, Disable to pause a server without losing its configuration, and Remove to delete it together with every user's authorization.
Authorize your account
For OAuth servers, every user authorizes separately:
- From Integrations > MCP servers, select Authorize on the server row and complete the sign-in in the window that opens.
- In a conversation, when the assistant needs a server you have not authorized yet, it shows an Authorize card. Authorize in the window that opens, then select Retry so the assistant continues.
When you ask the assistant in Slack and it needs a server you have not authorized, it posts an Authorize message with a button that opens the server in the console. Authorize there, then reply try again in the Slack thread. Write actions in Slack ask for confirmation with Run and Cancel buttons, exactly as in the console.
Your access shows whether your authorization is active. Select Revoke my access at any time; administrators and DoiT staff can see who has authorized a server, but never the tokens themselves.
Using connected tools
Once a server is connected and you are authorized, ask the assistant naturally, for example:
Is there already a Linear issue about yesterday's EKS anomaly? If not, open one for the platform team.
The assistant picks connected tools when they are relevant, exactly as it picks its built-in tools. Before it runs a write action it shows the request and waits for your confirmation. Anything a connected server returns is treated as data: the assistant never follows instructions found inside a tool result.
To point the assistant at specific servers, select Add in the chat composer, open Connected tools, and pick one or more servers. Each selection appears as a chip next to your message and stays attached to the conversation until you remove it. With a selection in place the assistant treats your request as being about those systems, whatever the wording, and uses their tools first. Servers you have not authorized yet show an Authorize button in the same list.
What is shared and stored
- Sent to the server: the arguments of each tool call, generated by the assistant from your conversation. Internal DoiT notes and cloud credentials are never sent.
- Stored by DoiT: the server's URL and tool definitions, the tool settings your administrators chose, and each user's OAuth tokens (in Google Secret Manager, never in the console database). Revoking your access deletes your tokens.