Claude Code MCP Servers: Connect to Internal APIs and Databases

Why MCP Changes What Claude Code Can Do

By default, Claude Code has access to your filesystem and the ability to execute shell commands. That's already powerful — it can read any file, run your test suite, query git history, and modify code across the entire repository. But enterprise developers work inside much richer tool ecosystems. Your database schema lives in a running PostgreSQL instance. Your API documentation lives in Confluence. Your infrastructure state lives in Terraform Cloud. Your deployment pipelines live in Jenkins or GitHub Actions.

Without MCP servers, Claude Code can only work with these systems indirectly — through files you've already exported, documentation you've manually copied in, or shell commands that return text output. With MCP servers configured, Claude Code can query your production database schema in real time, look up API endpoints as it writes integration code, check current infrastructure state before modifying Terraform files, and trigger deployments directly from the terminal session.

The Model Context Protocol was designed specifically for this pattern: giving AI tools structured, secure access to external systems through a standard interface. Claude Code has native MCP support as of early 2026, and configuring it correctly for an enterprise environment is the single biggest multiplier on developer productivity after the initial Claude Code setup.

How Claude Code MCP Integration Works

MCP servers are lightweight processes that expose a defined set of tools and resources over a standard JSON-RPC interface. When Claude Code is configured to use an MCP server, it can discover what tools and resources that server provides, call those tools during a session, and incorporate the results into its reasoning and code generation.

The key architectural point is that Claude Code does not connect to your database directly. It connects to an MCP server that you control, which then connects to your database with the credentials and access controls you define. This means you can implement authentication, rate limiting, read-only enforcement, and audit logging at the MCP server layer — without any of those constraints changing how Claude Code behaves in the session.

This architecture is what makes MCP suitable for enterprise use. Your database credentials never touch Claude Code or Anthropic's infrastructure. Your internal APIs are accessed through a proxy you control. Security and governance remain with your team. For more on the governance model, our MCP server development service includes security architecture design as a core deliverable.

MCP Server Configuration in Claude Code

MCP servers are configured in Claude Code's settings file, which lives at ~/.claude/settings.json for user-level configuration, or in the project's .claude/settings.json for project-scoped servers. The project-level configuration is the right approach for enterprise deployments — it version-controls the MCP configuration alongside the codebase and ensures every developer on the team uses the same server setup.

// .claude/settings.json — project-level MCP configuration
{
  "mcpServers": {
    "postgres-schema": {
      "command": "node",
      "args": ["./mcp-servers/postgres-schema/index.js"],
      "env": {
        "DB_HOST": "${DB_HOST}",
        "DB_NAME": "${DB_NAME}",
        "DB_USER_READONLY": "${DB_USER_READONLY}",
        "DB_PASS_READONLY": "${DB_PASS_READONLY}"
      }
    },
    "internal-api-docs": {
      "command": "python",
      "args": ["-m", "mcp_api_docs"],
      "env": {
        "API_REGISTRY_URL": "https://api-registry.internal.yourco.com",
        "API_TOKEN": "${API_REGISTRY_TOKEN}"
      }
    }
  }
}

Notice that credentials are passed as environment variable references — ${DB_HOST} rather than literal values. The actual secrets live in your developer's environment or in a secrets manager, not in the settings file that's committed to version control. This is the correct pattern for enterprise deployments.

Building MCP Servers for Internal Systems

Anthropic provides the @modelcontextprotocol/sdk for Node.js and a Python SDK for building MCP servers. The programming model is straightforward: you define tools (functions Claude Code can call) and resources (data Claude Code can read), and the SDK handles the protocol layer.

Database Schema Server

The most universally useful MCP server for software development teams is one that exposes your database schema. Rather than asking developers to manually export DDL and paste it into CLAUDE.md, a schema server lets Claude Code query the live schema — always current, never stale — as it writes queries, builds migrations, or reviews ORM models.

// mcp-servers/postgres-schema/index.js
const { Server } = require('@modelcontextprotocol/sdk/server/index.js');
const { StdioServerTransport } = require('@modelcontextprotocol/sdk/server/stdio.js');
const { Pool } = require('pg');

const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER_READONLY,
  password: process.env.DB_PASS_READONLY,
  ssl: { rejectUnauthorized: true }  // Always use SSL in production
});

const server = new Server(
  { name: 'postgres-schema', version: '1.0.0' },
  { capabilities: { tools: {} } }
);

server.setRequestHandler('tools/list', async () => ({
  tools: [{
    name: 'get_table_schema',
    description: 'Get the column definitions and constraints for a database table',
    inputSchema: {
      type: 'object',
      properties: {
        table_name: { type: 'string', description: 'Table name' },
        schema_name: { type: 'string', default: 'public' }
      },
      required: ['table_name']
    }
  }, {
    name: 'list_tables',
    description: 'List all tables in the database schema',
    inputSchema: { type: 'object', properties: {} }
  }]
}));

The critical implementation detail is the read-only database user. The MCP server connects with a user that has SELECT privileges only — it cannot modify data, create tables, or execute stored procedures. This prevents Claude Code from accidentally (or through a prompt injection attack) altering your production database schema during a development session.

Internal API Documentation Server

If your organisation has an internal API registry — an OpenAPI catalogue, a Confluence space with API documentation, or a custom developer portal — an MCP server that exposes this to Claude Code is extremely valuable. Claude Code can look up endpoint signatures, authentication requirements, and request/response schemas as it writes integration code, rather than relying on documentation that may be weeks out of date.

The pattern here is similar: your MCP server queries your internal documentation system with a service account, exposes tools like search_apis, get_endpoint_spec, and get_auth_requirements, and Claude Code calls these tools during code generation sessions. The developer never has to manually copy API documentation into their context window.

MCP Security Considerations for Enterprise

MCP servers significantly expand what Claude Code can access and do. With that expanded capability comes expanded attack surface — specifically, prompt injection attacks where malicious content in files Claude Code reads attempts to instruct the MCP server to take harmful actions.

The defences are architectural. MCP servers should operate with the principle of least privilege: read-only access to databases, scoped API tokens, and no write operations unless explicitly required for the use case. Even if Claude Code is manipulated into calling a tool with unexpected arguments, the underlying system should reject or safely handle those requests.

For a deeper treatment of MCP security architecture, read the MCP Protocol enterprise guide, which covers authentication, transport security, permission scoping, and audit requirements in detail. If you're running Claude Code in a regulated environment — financial services, healthcare, government — the security design for your MCP servers needs to be reviewed before they're deployed to production developer machines.

Deploying MCP Configuration Across a Development Team

Getting MCP servers running on one developer's laptop is a tutorial exercise. Getting them running consistently across a team of 50 engineers — with the right credentials, the right server versions, and the right access controls — is an operations problem. This is where enterprise Claude Code deployments diverge from individual use.

The recommended approach for teams is to maintain the MCP server code in a dedicated repository (or a subdirectory of the main monorepo), containerise each server so the runtime is consistent, and use a bootstrap script that handles server installation, credential setup, and configuration file population from a central source. Every developer runs the same bootstrap script when setting up their workstation — the MCP infrastructure is provisioned automatically.

Credential management at team scale requires integration with your secrets manager. Rather than each developer managing environment variables manually, configure the bootstrap script to pull credentials from AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault at setup time. This also makes it straightforward to rotate credentials — update the secret in your vault and re-run the bootstrap; no developer needs to manually update their local environment.

Our Claude Code enterprise deployment service covers team-scale MCP setup as a standard component. We've shipped this across engineering teams from 20 to 300 developers, and the patterns for doing it right are well-established. The enterprise setup guide has more detail on the broader deployment architecture that MCP servers slot into.

MCP Server Best Practices: What We've Learned in Production

Start with read-only servers. The first MCP servers you deploy should expose no write operations. This reduces risk dramatically while still providing enormous value — schema queries, documentation lookup, and state inspection cover most of what Claude Code needs to write better code.

Version your server APIs carefully. When you update an MCP server's tool signatures, Claude Code sessions configured against the old version will break. Maintain backwards compatibility in tool schemas, or version your servers explicitly and update CLAUDE.md configurations as part of any breaking change.

Instrument everything. MCP server calls are an audit trail of what Claude Code accessed during a development session. Log every tool call with the timestamp, the developer identity, the arguments, and the response. This is essential for security investigations and useful for understanding how developers are actually using Claude Code in practice.

Handle errors gracefully. Claude Code will continue working if an MCP server is unavailable — it simply won't have that context. Design your servers to return clear error messages rather than hanging, and document which tools are available offline versus requiring connectivity to internal systems.

If you're evaluating Claude Code for your engineering organisation and want to understand how MCP servers fit into the broader Claude AI strategy, book a free architecture call with our team.