When you want to answer a question about your database estate, you normally have to know which Monitor screen to open and dig through it yourself. That is fine for a deep investigation, but it can be frustrating to click through several screens and hold all the pieces together in your head just to answer one question. The Model Context Protocol (MCP) solves this by letting you connect an MCP client (an AI assistant such as Claude Code or VS Code Copilot) to your self-hosted Redgate Monitor. Once connected, the client uses a set of read-only tools to fetch answers directly from Monitor. So you can simply ask, in plain English, "find me the worst performing queries across my monitored servers" and let the client gather the answer for you. 

What you can do today

Everything the MCP server exposes is read-only. See the table below for tools that the MCP client can use.

Security

The MCP server is designed to be safe to connect an MCP client to:

• Read-only. The available tools can only read data; they cannot change anything in Monitor or on your databases.
• HTTPS only. Connections are encrypted; plain HTTP is rejected.
• Dedicated, scoped token. Access uses a least-privilege MCP-role token that you scope to specific servers and can revoke at any time by deleting it.
• Rate limited. Each token is throttled to protect your Monitor installation. By default its 60 tool calls per minute. (See Configure the rate limit).
• Logged. Every request to the MCP server is logged.

Before you start

You will need:

• To be running version 14.28 or later of Redgate Monitor.
• You need to be on a Redgate Standard or Redgate Enterprise license rather than a legacy Perpetual license.
• You need the HTTPS address of your Monitor Web server (for example https://monitor.your-company.com). MCP is only available over HTTPS. If your Monitor is not yet on HTTPS, follow Configuring HTTPS for the default Redgate Monitor web server.
• Administrator access to Monitor to create an MCP access token.
• A supported MCP client on your machine. This preview currently supports only the following two clients:
  • Claude Code (CLI) - run claude --version to confirm it is installed.
  • VS Code Copilot.
• Tested with Claude Sonnet and Claude Opus. It is expected to work with equivalent models from other providers (e.g. OpenAI, Google), since MCP is an open, provider-agnostic protocol but these have not been explicitly verified by our team.
• The ability to connect an MCP server in your MCP client. By default, anyone running Claude Code can connect any MCP server they choose. Some organizations disable this; if yours has, ask your Claude Code admin to enable MCP servers using the managed MCP documentation. For VS Code Copilot, see the MCP servers documentation.

Create a dedicated MCP access token

The MCP server only accepts a token created specifically for it: a token with the MCP role. Create a dedicated token for this; do not reuse an Administrator or REST API token.

1. Go to Configuration > Access tokens and choose Create new token.
2. Give the token a name (and optionally a description) and set an expiry date.
3. Under Choose token role, select MCP ("Read-only access for MCP tools").
4. Under Access rights, choose which servers the token may see. The token can only ever read data for the servers you select here, so you can scope it as narrowly as you like.
5. Select Create.
6. Copy the generated token now - it is shown only once. Store it somewhere safe; you will paste it into your MCP client in the next step.

Connect your MCP client

Use the Monitor address from your browser and the MCP token you just copied.

Claude Code (CLI)

Run this in a terminal, replacing the placeholders with your Monitor address and token:

claude mcp add --transport http redgate-monitor https://<your-monitor-host>/mcp --header "Authorization: Bearer <your-mcp-token>"

You should see a confirmation such as "Added HTTP MCP server redgate-monitor".

VS Code Copilot

1. Paste the following instructions to co-pilot AI and provide it the Monitor host url. It will configure it for you, and once configured press Start and input the token when prompted. Otherwise follow the steps manually.

2. Press Ctrl + Shift + P, type MCP: Open User Configuration, and open the mcp.json file.

3. Add the Redgate Monitor server. If the file already has content, place the entry inside the existing servers section and add the input to the inputs array: 

   {
     "servers": {
       "redgate-monitor": {
         "type": "http",
         "url": "https://<your-monitor-host>/mcp",
         "headers": {
           "Authorization": "Bearer ${input:redgate-mcp-token}"
         }
       }
     },
     "inputs": [
       {
         "id": "redgate-mcp-token",
         "type": "promptString",
         "description": "Redgate Monitor MCP token",
         "password": true
       }
     ]
   }

4. Save the file (Ctrl + S).

5. Press Ctrl + Shift + P, type MCP: List Servers, select redgate-monitor, and choose Start. When prompted, paste your MCP token and press Enter.

Verify the connection

• Claude Code: start Claude Code (claude), then type /mcp. The redgate-monitor server should appear with a connected status. 
• 
• VS Code Copilot: the redgate-monitor server should show as running.
• 
• Then try asking your MCP client:

"What servers are being monitored?"

If you get a list of your monitored servers back, the connection is working.

Troubleshooting

Example prompts to get started

• To know the current status of the estate:
  Summarise the current state of my monitored estate. Retrieve all monitored servers and group them to show how many instances of each type I have (SQL Server, PostgreSQL, etc.), how they're distributed across server groups, and how many are currently healthy versus not actively monitored or in a non-running state. Before summarising, ask whether I want to narrow the overview to a specific server group, and wait for my response before continuing - if I don't specify one, cover the full estate. Present a concise breakdown with counts, and flag anything that isn't being monitored normally - but do not suggest investigating or drilling into it. This is an overview only: do not query metrics or individual queries, and do not propose any follow-up actions, next steps, or offers to drill into specific instances. End with the summary only.
• To find out the problematic queries across the estate:
  Show the most resource-intensive SQL Server queries over the last 2 hours. First list my monitored SQL Server instances and ask which to check — up to 25, or blank for all (if more than 25, use the first 25 and say so). In the same question, ask whether I want to narrow the selection by server group and whether to filter or sort the results by a specific database, and wait for my response before continuing. For each chosen instance, retrieve its top queries ranked by impact over the last 2 hours and summarise the worst offenders - include the query text and what makes each expensive (duration, CPU, reads). Treat each instance independently: do not compare or rank queries across different instances.
• To understand resource usage across the estate: 
  Check CPU and memory health for my SQL Server instances over the last 2 hours. First list my monitored SQL Server instances and ask which to check — up to 25, or blank for all (if more than 25, use the first 25 and say so). In the same question, ask whether I want to narrow the selection by server group, and wait for my response before continuing. For each chosen instance, retrieve SqlServerCpuPercentage for the instance, MachineCPUPercentage and MachineMemoryUsed for its host machine, all over the last 2 hours. Analyse the data across the time range to calculate a baseline for each metric, then use that baseline to identify any spikes, sustained pressure, or trends. Always tell me the calculated baseline values, then summarise whether instance CPU, host CPU, and host memory look elevated, sustained, or trending and flag anything under pressure.

Configure the rate limit (optional)

To protect your Monitor installation, each MCP token is rate limited. By default it allows 60 requests every 60 seconds per token, which is plenty for normal use, so most people can skip this section.

If you want to change it, add an Mcp section to the same appsettings.json file you edited in Turn on the MCP server (C:\ProgramData\Red Gate\Redgate Monitor\appsettings.json):

{
  "Mcp": {
    "RateLimiter": {
      "Enabled": true,
      "RequestsPerInterval": 60,
      "IntervalSeconds": 60
    }
  }
}

• Enabled - set to false to turn the rate limit off entirely (not recommended).
• RequestsPerInterval - how many requests each token may make in one interval.
• IntervalSeconds - how long that interval lasts, in seconds.

For example, to allow 120 requests per minute, set RequestsPerInterval to 120 and leave IntervalSeconds at 60. As with turning the server on, restart the Redgate Monitor Web Service after saving for the change to take effect.