How to Connect Claude AI to SQL Server: A Step-by-Step Guide

The setup in plain English

Claude cannot read your SQL Server database simply because you ask it to. It needs a supported connection to software that can retrieve the data. The Model Context Protocol, or MCP, provides a standardized way for an AI application to discover tools and request actions from an external service.

For database questions, the path typically looks like this:

Connecting the two systems is not the same as granting everyone access. A sales employee who can see orders should not automatically be able to query payroll, even if both live in the same database. That is why the setup should begin with least-privilege SQL permissions and employee-level scopes, not just a connector URL.

What you need before connecting

Before opening Claude, have a small test environment ready. You will need:

• A SQL Server database that your chosen MCP service can reach over an approved network path.
• A dedicated database account with only the read permissions required for the pilot. Avoid using sa or an unrestricted administrator account.
• At least one safe table or reporting view containing sample or non-sensitive business data.
• An MCP server or managed platform such as ScopeBase that supports the database and can enforce access rules.
• Permission to configure custom connectors in your Claude account or organization.

For a remote Claude connector, the MCP endpoint must also be accessible from Anthropic's cloud infrastructure over HTTPS. A URL that works only from your laptop or company VPN may not work from Claude. Network and authentication requirements depend on your deployment.

Step 1: Connect SQL Server to your MCP access layer

In ScopeBase, configure the SQL Server connection using the details for your database and test that the service can connect. Once connected, use its database discovery tools to review the available objects. Discovery helps you identify what may be exposed; it should not automatically make every discovered table available to employees.

Keep the initial scope narrow. A useful first example is an approved sales reporting view with order dates, totals, and product categories—without payment details or personal identifiers.

Microsoft documents how SQL Server permissions can be granted at the object, schema, or database level. For this use case, specific object-level grants are generally a safer starting point than database-wide SELECT access.

Step 2: Configure scopes and assign employees

For one person experimenting with a database, a single connection can look sufficient. For a company, it is the wrong stopping point. Different employees have different responsibilities, so they should not inherit the same effective access merely because they use the same Claude connector.

In ScopeBase, a scope is the permission group that determines which database information an assigned employee may access. For example, you might create a Sales scope with approved sales and inventory objects, then assign members of your sales team to that scope. Finance can have a separate scope for its own approved reporting data.

These are illustrative policies, not default permissions. The administrator still decides exactly which objects and employees belong in each scope. A scope needs to be enforced when a query executes—not merely described in a prompt telling Claude what it should avoid.

Step 3: Add your ScopeBase MCP connection to Claude

Once the SQL connection and employee scopes are ready, use the remote MCP URL provided by your configured ScopeBase environment. Claude's exact menus can change, but its current custom connector flow distinguishes individual subscriptions from managed workspaces.

For an individual Claude account

1. In Claude, open Customize → Connectors.
2. Choose the option to add a custom connector.
3. Enter a descriptive name such as ScopeBase and paste the remote MCP server URL.
4. Review the authentication method offered for that endpoint and complete the connection.
5. In a Claude conversation, enable the connector from the connectors/tool controls before testing.

For a Claude Team or Enterprise workspace

An authorized workspace owner or administrator first adds the custom web connector through the organization's connector settings. Employees can then find that connector under Customize → Connectors and connect individually when supported by the chosen authentication method.

Important: do not assume that separate Claude logins automatically mean separate database permissions. If the MCP connection uses one shared API key or a shared identity, every employee may effectively inherit that shared identity's access. Confirm how your ScopeBase deployment identifies each requester and selects their scope.

For the current Claude instructions and account-specific options, see Claude's official custom connector guide.

Step 4: Test both an allowed question and a blocked question

Use a test employee who is assigned to a narrowly defined scope. First, ask a question based on a permitted reporting object, such as:

Check the result against a known SQL report. An AI-generated explanation can be fluent and still contain an incorrect number, filter, or date range. Confirm what “sales” means, which timestamp is used, and which records are included.

Then ask for something that is outside that employee's permission scope:

The expected outcome is a server-enforced denial of unauthorized data access, not a polite promise from Claude to avoid the table. If the query succeeds when it should not, stop the rollout and fix the policy or identity mapping.

When Claude cannot connect: what to check

A successful ScopeBase health check does not necessarily prove Claude can discover tools or execute SQL through its remote connector. When the connection fails, check the path in this order:

• DNS and TLS: the configured MCP hostname must resolve publicly and present a valid HTTPS certificate.
• Reachability: Cloudflare, reverse proxies, firewalls, and network allowlists must permit the Claude-originated connection required by your chosen setup.
• Authentication: the connector must use the auth flow actually configured by the MCP endpoint; a working public status route is not proof that protected tools authenticate.
• Authorization: the employee must be recognized and have an appropriate scope assigned.
• SQL access: the backend database login still needs permission to query approved objects.

Keep operational error logs free of passwords, bearer tokens, and connection strings. Capture enough request context to troubleshoot without recording unnecessary business data.

Before inviting your whole team

A working demonstration is a starting point, not a full production security review. Validate limits on query execution time and result size, review which database objects are discoverable, and define who can change employee permissions. Plan how access is revoked when someone changes roles or leaves the company.

Start with one department and a small set of well-defined reporting questions. Record which questions employees actually ask, whether the answers match approved reports, and whether the access restrictions hold. That feedback tells you whether to expand the scope or improve data definitions.

Where ScopeBase helps

ScopeBase brings together SQL database connectivity, scoped data access, and employee assignments for teams using compatible AI clients. Instead of building your own employee permission workflow around a generic MCP server, administrators can manage those assignments through ScopeBase.

If you prefer to see the process before configuring anything, watch the ScopeBase product walkthrough. You can also read how employee scopes work in a business rollout.