SQL Server MCP tools for your AI assistant in DataGrip

JetBrains IDEs from version 2025.2 have a built-in MCP server. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other programs. QueryScope adds eight SQL Server tools to that server. An assistant connected to your IDE can then answer "why is this query slow?", "what got slower since the deployment?" and "who is blocking whom right now?" from the plans and Query Store of your real database, through the data sources you already have in DataGrip.

What the assistant can do

• Get the estimated plan of a query or batch. SQL Server only compiles it; nothing runs.
• Get the actual plan of a SELECT. It runs once, inside a transaction that is rolled back.
• See current blocking chains, head blockers first.
• Read Query Store: the top queries by CPU, duration or reads, the queries that got slower with the plan change behind it, every plan of a query, and a summary of any stored plan.
• List the SQL Server data sources of the project.

Set it up

1. Install QueryScope from JetBrains Marketplace in DataGrip or another JetBrains IDE with Database Tools, version 2025.2 or later. The 30-day trial covers the MCP tools.
2. Turn on the IDE's MCP server and connect your MCP client, as described in JetBrains' MCP server documentation. In current versions: Settings | AI | MCP Server, select Enable MCP Server, then click Auto-Configure for your client.
3. Ask your assistant about a SQL Server data source. The tools use the IDE's own connection, so QueryScope never asks for or stores a password.

We tested the tools with the official MCP TypeScript SDK as the client, in DataGrip 2025.2 and 2026.3, against SQL Server 2019, 2022 and 2025. We have not tested JetBrains AI Assistant, Junie, Claude Desktop or Cursor ourselves.

Example: a slow lookup with an implicit conversion

The assistant asks for the estimated plan of SELECT OrderId, Amount FROM dbo.Orders WHERE Code = N'C12345'. This is part of what QueryScope answers:

The query was not run: SQL Server only compiled it (SET SHOWPLAN_XML ON).
Statement 1: SELECT, estimated cost 0.2862, estimated rows 1, optimization FULL, compiled in 0 ms.
  Operators: 3. Costliest (share of the estimated statement cost):
    - 82.6% node 2 Index Scan on [qs_mcp_test].[dbo].[Orders].[IX_Orders_Code]; est. 1 rows;
      predicate: CONVERT_IMPLICIT(nvarchar(20),[qs_mcp_test].[dbo].[Orders].[Code],0)=N'C12345'

The CONVERT_IMPLICIT shows the cause: Code is a varchar column and the query compares it with an nvarchar literal. nvarchar has the higher data type precedence, so SQL Server converts the column, and the plan scans the index with the conversion in the predicate. Comparing with a value of the column's own type avoids that conversion.

Example: a missing index

Statement 1: SELECT, estimated cost 1.8335, estimated rows 785, optimization FULL, compiled in 0 ms.
  Text: SELECT OrderId FROM dbo.Orders WHERE Amount = 42
    - 100.0% node 0 Clustered Index Scan on [qs_mcp_test].[dbo].[Orders].[PK__Orders__…]; est. 785 rows
  Missing index suggestions from SQL Server (check them before creating; they ignore existing indexes and write cost):
    - impact 99.7%: CREATE NONCLUSTERED INDEX [IX_Orders_Amount] ON [dbo].[Orders] ([Amount])

Example: what got slower since the deployment?

The assistant asks Query Store for regressed queries since a given time. QueryScope compares that window with the hour before it and shows the plan change:

1. Query 1 (dbo.OrdersOfCustomer): 14.1 reads -> 2,363 reads per run (168x worse); 40 runs before, 41 runs recently;
   extra 96,307 reads in the recent window.
   PLAN CHANGED: the baseline window ran plan 1 most, the recent window plan 3. Forced plan: none.

It can then summarize both plans: plan 1 was an Index Seek with a Key Lookup, plan 3 a Clustered Index Scan of an estimated 60,000 rows. Forcing the good plan is a decision for you: the MCP tools never force a plan. In the QueryScope tool window, Force Plan is one click after a confirmation.

Example: who is blocking?

1 head blocker, 1 blocked session. Head blockers first; every blocked session is listed under the session it waits for.

1. Head blocker session 68 (sleeping), idle with an open transaction, blocks 1 session (1 directly)
   Open transactions 1, oldest open transaction 2 s.
   Last batch it sent: BEGIN TRANSACTION; UPDATE dbo.Orders SET Amount = Amount + 1 WHERE OrderId = 1;
   - session 73 (suspended, select), waits 1.7 s on LCK_M_S

A sleeping session with an open transaction is the classic cause: the application started a transaction and never committed it. The MCP tools never kill a session; in the QueryScope tool window, Kill session is available after a confirmation.

What the tools will not do

• Change data. A batch with anything other than SELECT queries is refused before it runs, for example: "This batch also contains: UPDATE. Nothing was run. Use queryscope_get_estimated_plan for this batch instead: it never runs the query."
• Kill sessions or force plans.
• Ask for or store passwords. They use the data sources and credentials already in the IDE.
• Work around permissions. When the login lacks a permission, the answer names it, with the GRANT statement to ask a DBA for.

Get QueryScope

The MCP tools are part of QueryScope, next to its Query Store view, blocking monitor, execution plan viewer and Extended Events capture. QueryScope costs $39 a year for individuals and $79 for organizations, with a 30-day trial: QueryScope on JetBrains Marketplace.