MCP Server for SQL Server: Connect With Clear Data Boundaries

An MCP server for SQL Server lets an AI assistant query your database, describe its schema, and help with analysis — without direct database access and without you copying data into a chat window. The assistant calls the server; the server runs controlled queries; the results come back as readable text.

Getting this right means deciding upfront what the AI may read, what it may not, and whether it can write anything at all. Tools like fenbs hold those decisions where every AI you connect reads them before starting work.

Why connect SQL Server to an AI assistant via MCP

SQL Server holds structured data that an AI can help explore: aggregates, joins, trend summaries, data quality checks. Without a connection, you copy query results into a chat, explain the schema from memory, and repeat that setup every session.

An MCP server makes the schema available to the AI directly, so it can write queries against real table names and column types. It also means the assistant never sees data it was not asked about, because the server only runs the specific queries the assistant submits.

Connection options

You have two practical approaches. The first is to run an open-source MCP server that wraps a SQL database connection. Several community-built options exist; search the mcp server directory for current choices and check each one's documentation for SQL Server compatibility.

The second is to build a minimal server yourself, using the official MCP SDK for TypeScript or Python, with a SQL Server client library (such as mssql for Node.js or pyodbc for Python). This approach gives you the tightest control over which queries the server will run.

Both approaches need a SQL Server connection string. Store it as an environment variable on the server, not in the MCP configuration file. Connection strings contain credentials; never paste them into a chat or a shared config.

Restrict access to what the AI needs

Connect the MCP server with a dedicated SQL Server login that has only the access the AI actually needs. For read-only analysis, that means SELECT on specific schemas or tables — not sysadmin, not db_owner, not even db_datareader on the whole database if most tables are irrelevant.

Create a separate SQL Server user for the MCP connection. Grant SELECT on the schemas you want the AI to see. If there are tables with personal data, financial records, or audit logs the AI should not touch, grant no access to those tables for this user.

• Read-only analysis: grant SELECT on the target schemas only.
• Write access for approved operations: grant INSERT or UPDATE on specific tables after a deliberate review of the risk.
• Never grant ALTER, CREATE, DROP, or TRUNCATE unless you have an explicit operational reason and human review for each action.
• Use a separate login for the MCP connection — do not reuse a developer or application account.

Expose schema context, not raw data

Give your MCP server a tool that returns schema information — table names, column names, and data types — without returning row data. The AI needs to know the structure to write useful queries. It does not need to see the actual records until it queries a specific one.

Most community SQL MCP servers include a schema-inspection tool. If you build your own, query INFORMATION_SCHEMA.COLUMNS filtered to the schemas your dedicated login can read. Return the result as structured text the AI can reference when writing subsequent queries.

Store a summary of the key tables and their purposes in fenbs as a context note. That way, an AI reading the project context understands the data model before it even calls the schema tool.

Review generated queries before trusting them

An AI assistant will write queries that look right and occasionally miss something — a missing WHERE clause, an unintentional cross join, or a query that touches more rows than you expected. Before running an AI-generated query against production data, review it.

One practical approach: start with a read-only connection to a development or staging database. Confirm the AI's queries produce correct results there before running equivalent queries against production. Use SQL Server's query execution plan to check for expensive operations before they run.

For queries that modify data, require explicit human approval before the MCP server will execute them. A tool that returns a proposed query for review, rather than running it immediately, adds a useful checkpoint without slowing down read operations.

Keep schema context and analysis decisions together

A useful SQL analysis session produces decisions as well as results: "this table is the source of truth for customer records," "the status column uses these four values," "we aggregate by fiscal quarter, not calendar quarter." Those conclusions should survive the chat.

Store them as context notes or Decisions and rules entries in fenbs. The next time you run a similar analysis — or a different AI assistant runs it — those facts are available at the start of the session rather than rediscovered by running the same exploratory queries again.

How to do this with fenbs

1. Create a free account and set up a project for the SQL Server analysis work.
2. Add Decisions and rules entries for the schemas the AI may access, the dedicated SQL login name, and any tables that are off limits.
3. Add a context note with a plain-language description of the key tables and their relationships. This helps AI assistants understand the data model without running schema queries first.
4. When an analysis session produces a useful finding — a data quality issue, a confirmed calculation method — record it as a context note or decision so it is available next time.
5. Connect your AI to fenbs over MCP from Integrations so it reads the approved data boundaries before writing any queries.

fenbs does not connect to SQL Server or store connection strings. It keeps the decisions and context your AI needs — the boundaries, the schema summaries, and the approved conclusions — in one place outside any single chat session.