Building Secure MCP Servers for Internal Enterprise Data

Integrating AI assistants into enterprise environments presents a unique challenge: how do you securely and efficiently connect them to your proprietary internal data? While many tutorials cover basic external integrations, the real power of AI in an organization comes from its ability to interact with internal databases, APIs, knowledge bases, and custom systems. This is precisely where the Model Context Protocol (MCP) shines, offering a standardized approach to unlock your internal data for AI.

What is the Model Context Protocol (MCP)?

MCP, an open protocol developed by Anthropic, establishes a universal standard for AI assistants to discover and invoke external tools. Think of it as a universal connector for AI – a single, consistent interface that allows any MCP-compatible AI model (like Claude, ChatGPT, or custom applications) to access any data source. Before MCP, integrating an AI with internal systems often meant creating custom tool definitions for each LLM provider, embedding data access logic directly into AI applications, and facing significant rework when models or data sources changed.

MCP decouples the data layer from the AI layer. Your MCP server exposes capabilities as tools (actions the AI can take) and resources (data the AI can read). This separation offers substantial benefits for internal data: your CRM, ERP, ticketing systems, and wikis can all become AI-accessible via one protocol. Access control remains centralized within your MCP server, new AI models gain immediate access without complex rewiring, and tool definitions are maintained close to the actual data, simplifying versioning and updates.

Architectural Overview

The MCP server acts as an intermediary between your AI client and your internal systems (e.g., PostgreSQL, internal APIs, file stores). Its responsibilities include:

• Tool Discovery: Announcing available operations to the AI.
• Parameter Validation: Ensuring AI-provided inputs conform to expected schemas.
• Data Access: Executing queries against your internal systems.
• Response Formatting: Structuring data for AI consumption.
• Authentication: Verifying client identities and permissions.

Building the MCP Server: Tools and Resources

The core of an MCP server lies in defining its tools and resources. These are the mechanisms through which AI can interact with your data.

We start by initializing an McpServer instance, declaring support for both tools and resources:

typescript import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { z } from "zod";

const server = new McpServer( { name: "internal-data", version: "1.0.0" }, { capabilities: { tools: {}, resources: {} } } );

Defining Tools

Tools represent actions the AI can take, such as searching an employee directory or listing projects. Good tool design is paramount for effective AI interaction. Each tool is registered with server.tool(), requiring a unique name, a descriptive plain-English explanation, a Zod schema for parameter validation, and an asynchronous handler function.

Key principles for effective tool design:

1. Descriptive Names and Descriptions: The AI relies solely on these to decide when to invoke a tool. Be explicit about the tool's purpose and conditions for use.
2. Typed Parameters with Descriptions: Use Zod's .describe() for every parameter. This provides the AI with clear guidance on expected input formats and meanings.
3. Structured Return Values: Format responses in a way the AI can easily reason about, such as markdown tables or structured lists, rather than raw JSON.

For example, connecting to a PostgreSQL database with employee data, you might define a search_employees tool:

typescript // src/db.ts (excerpt) // ... functions like searchEmployees(query: string, department?: string): Promise<Employee[]>

// src/tools.ts (excerpt) server.tool( "search_employees", Search the internal employee directory by name, email, or role. Returns matching employees with their department and reporting structure. Use this when the user asks about people, teams, or org structure., { query: z.string().describe("Search term: employee name, email, or role title"), department: z.string().optional().describe("Filter by department name (e.g., 'Engineering', 'Marketing')"), }, async ({ query, department }) => { const employees = await searchEmployees(query, department); // ... format and return results } );

Exposing Resources

Resources provide read-only data that the AI can load as background context, typically upfront. They differ from tools in that they offer context rather than enabling actions. Examples include company policies, API documentation, or database schemas. Resources can be static (fixed URI) or dynamic, using ResourceTemplate for patterns like internal://departments/{name}.

typescript // src/resources.ts (excerpt) import { McpServer, ResourceTemplate } from "@modelcontextprotocol/sdk/server/mcp.js";

export function registerResources(server: McpServer) { server.resource( "org-structure", "internal://org-structure", { description: "Overview of the organization structure", mimeType: "text/markdown" }, async (uri) => ({ contents: [/* ... content ... */] }) );

server.resource( "department-info", new ResourceTemplate("internal://departments/{name}", { list: undefined }), { description: "Detailed information about a specific department", mimeType: "text/markdown" }, async (uri, variables) => ({ contents: [/* ... content for variables.name ... */] }) ); }

Authentication: The Security Imperative

For internal data, authentication is non-negotiable. MCP servers must validate requests to prevent unauthorized access. The simplest method is Bearer Token Authentication, implemented via an Express middleware that intercepts all MCP requests:

typescript // src/auth-middleware.ts (excerpt) export function authMiddleware(req: Request, res: Response, next: NextFunction) { const authHeader = req.headers.authorization; if (!authHeader?.startsWith("Bearer ")) { return res.status(401).json({ error: "Missing authorization header" }); } const token = authHeader.slice(7); try { const claims = validateInternalToken(token); // Replace with your actual validation // ... attach userId, orgId to request next(); } catch { return res.status(403).json({ error: "Invalid token" }); } } // app.use("/mcp", authMiddleware); // Add to your Express app

This authMiddleware validates a token against your internal authentication system (e.g., JWT verification, API key lookup, session validation). The validated user and organization IDs can then be used by your tool handlers for fine-grained access control. For clients supporting it, MCP also offers a built-in OAuth 2.0 flow for more complex authentication needs.

Transport and Production Deployment

MCP supports various transports. For production internal data servers, Streamable HTTP is generally recommended. This involves setting up a single Express endpoint (e.g., /mcp) to handle all MCP communication, maintaining stateful sessions via mcp-session-id headers. The SDK's StreamableHTTPServerTransport manages this complexity.

For local development or when an MCP client (like Claude Desktop) spawns the server as a child process, StdioServerTransport is convenient, communicating over stdin/stdout. However, for a production environment, HTTP is typically preferred due to its scalability and network compatibility.

Deploying to production involves standard practices such as Dockerizing your MCP server for consistency, implementing health checks, and setting up robust logging and audit trails to monitor usage and ensure compliance. These operational considerations are crucial for maintaining a reliable and secure AI integration layer.

Practical Takeaways

Building MCP servers for internal data requires a thoughtful approach to tool design, robust authentication, and mindful deployment. By adhering to principles of clear tool descriptions, strong parameter typing, and secure access patterns, you can create a powerful and flexible bridge between your organization's valuable internal data and the rapidly evolving world of AI assistants. This empowers your AI clients to operate with an unprecedented level of context and capability, transforming how your organization leverages AI.

FAQ

Q: How does MCP handle multi-tenancy for internal data?

A: Multi-tenancy is handled primarily within your MCP server's authentication and data access layers. After authenticating a user or client (e.g., via Bearer token validation), the server can extract tenancy information (like orgId). This orgId is then used by your data access logic (e.g., searchEmployees in src/db.ts) to filter queries and ensure users only access data relevant to their organization or assigned scope.

Q: What are the key differences in choosing between StreamableHTTPServerTransport and StdioServerTransport for a production internal MCP server?

A: StreamableHTTPServerTransport is the recommended choice for production internal MCP servers as it runs over HTTP, making it suitable for remote, networked deployments. It supports persistent sessions via mcp-session-id headers and can be easily integrated into existing web infrastructure. StdioServerTransport, while excellent for local development or when the AI client directly spawns the server as a child process, is generally not used for remote production deployments due to its reliance on standard input/output streams rather than network protocols.