What is MCP and why does it matter for enterprise Claude?

Model Context Protocol (MCP) is an open standard from Anthropic that defines how AI models like Claude connect to external data sources and tools. For enterprises, MCP is the foundational layer that transforms Claude from a standalone chat interface into an integrated assistant that can read from your knowledge bases, query your databases, create tickets in your project management tools, and interact with virtually any internal system. Without MCP, Claude works on text you paste in. With MCP, Claude works on your actual data, in your actual systems, in real time.

Is MCP secure for enterprise use?

MCP security depends primarily on how you implement the server-side components. Best practices include: running MCP servers inside your network perimeter (never exposing them directly to the internet), implementing OAuth 2.0 or API key authentication for each server, logging all MCP tool calls with the same rigour as direct API access, applying the principle of least privilege (each MCP server should have the minimum permissions needed), and reviewing MCP server code before deployment — particularly for servers that can modify data rather than just read it.

What systems can MCP connect Claude to?

The MCP ecosystem includes hundreds of pre-built servers. Common enterprise connections include: Slack, Microsoft Teams, Jira, Confluence, GitHub, GitLab, Salesforce, HubSpot, PostgreSQL, MySQL, MongoDB, Google Drive, SharePoint, Notion, Zendesk, PagerDuty, and most REST APIs via a generic HTTP server. For proprietary internal tools, teams write custom MCP servers — typically 50-200 lines of Python or TypeScript.

How long does MCP setup take in an enterprise?

For a single pre-built MCP server connecting to a well-documented API (e.g., Slack or GitHub), setup typically takes 1-3 hours including testing. For a full enterprise integration package — 5-10 servers covering the primary engineering and business tools — expect 2-4 days of engineering time. Custom MCP servers for proprietary internal tools add 1-3 days per server depending on the complexity of the underlying API. Our managed MCP deployment service covers all of this end-to-end.

Can non-engineers manage MCP servers?

Once MCP servers are deployed and configured, day-to-day management requires minimal technical skill — primarily monitoring connection health and rotating API keys. The initial setup does require engineering involvement for server deployment, network configuration, and authentication setup. Most enterprises appoint a 'Claude infrastructure owner' in their engineering team who manages the MCP server layer while business users interact with Claude through the normal Claude interface without needing to know the MCP layer exists.

MCP Servers Setup Guide for Enterprise

What MCP Actually Is (and Why It Changes Everything)

The Model Context Protocol (MCP) is an open standard from Anthropic that defines how AI models connect to external data sources and tools. If you've used Claude and wished it could "see" your Jira tickets, query your database, or post to your Slack channels directly — MCP is what makes that possible.

Without MCP, Claude is powerful but isolated: you paste context in, Claude responds, you manually act on the output. With MCP, Claude becomes genuinely integrated: it reads your GitHub issues, queries your PostgreSQL database, creates Jira tickets, sends Slack messages, and calls your internal APIs — all within a single conversation, with full context about what it's touching.

In our experience across 200+ enterprise deployments, MCP integration is consistently the inflection point where teams move from "Claude saves me time" to "Claude fundamentally changes how work gets done." The difference between Claude-as-chatbot and Claude-as-integrated-assistant is almost entirely about whether MCP is in place.

The architecture is straightforward: MCP servers are small programs that expose tools and resources to Claude through a standardised protocol. They run locally or on your infrastructure, handle the authentication to your systems, and translate Claude's requests into the appropriate API calls. Claude itself never touches your systems directly — the MCP server acts as a structured intermediary.

Free Assessment

Ready to Connect Claude to Your Enterprise Stack?

Get a personalised MCP integration roadmap identifying which systems to connect first, security architecture recommendations, and implementation timeline for your specific tech stack.

Request Free Assessment →

MCP Architecture for Enterprise

Understanding the MCP architecture before implementation prevents the most common mistakes. MCP has three core concepts: servers (the programs that connect Claude to your systems), tools (functions that Claude can call, like "create_jira_ticket" or "query_database"), and resources (data sources that Claude can read, like "confluence_pages" or "github_repository").

The typical enterprise deployment pattern looks like this: Claude (running locally or via the API) connects to multiple MCP servers, each responsible for one system or a logical cluster of related systems. A developer's local Claude setup might connect to: a GitHub MCP server, a Jira MCP server, a local database MCP server, and an internal documentation MCP server. An enterprise API deployment connects to centralised MCP servers running in your infrastructure, handling authentication and access control centrally.

The security architecture decision — local MCP servers vs. centralised MCP servers — is the most consequential architectural choice in an enterprise MCP deployment. Local servers (running on each user's machine) are simpler to set up but harder to govern. Centralised servers (running in your infrastructure, with per-user authentication) are more complex but far easier to audit, update, and control. For enterprises beyond 20 Claude users, centralised MCP servers are almost always the right architecture.

Step-by-Step Enterprise MCP Setup

Step 1: Define Your Integration Scope

Before writing a line of configuration, map which systems Claude should connect to and with what permissions. For each system, answer: (1) What should Claude be able to read? (2) What should Claude be able to write/create/modify? (3) Who should have access? (4) What audit logging is required? This scoping exercise catches most security issues before they become problems.

Typical enterprise starting sets: Engineering teams start with GitHub + Jira + Confluence + their internal docs system. Customer support teams start with Zendesk + Confluence + CRM. Legal teams often start with read-only access to document repositories before considering any write capabilities.

Step 2: Set Up Your First MCP Server (GitHub Example)

The GitHub MCP server is the most common starting point for engineering teams and a good model for all MCP setups. Configure it by adding to your Claude Desktop or Claude Code configuration:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your_token_here"
      }
    }
  }
}
    

For enterprise deployments, replace the personal access token with a GitHub App installation token scoped to specific repositories. This allows per-user permission controls, audit logging at the GitHub App level, and easy token rotation without disrupting users.

Step 3: Connect to Your Internal Tools

Jira, Confluence, Slack, and most enterprise tools have community or official MCP servers available. The configuration pattern is similar: provide credentials, define the scope of access, and add the server to your MCP configuration. For Jira:

{
  "mcpServers": {
    "jira": {
      "command": "npx",
      "args": ["-y", "@anthropic-mcp/jira"],
      "env": {
        "JIRA_URL": "https://yourorg.atlassian.net",
        "JIRA_EMAIL": "claude-service@yourorg.com",
        "JIRA_API_TOKEN": "your_api_token"
      }
    }
  }
}
    

Use a dedicated service account for each MCP server — never individual user credentials. This makes it immediately clear in your audit logs which actions were taken by Claude, enables easy permission management, and ensures token rotation doesn't break individual users' setups.

Free White Paper

MCP Servers: Connecting Claude to Your Enterprise Stack

The complete enterprise guide to MCP architecture, security patterns, and integration playbooks for 15+ common enterprise systems. Includes configuration templates and approval workflows.

Download Free →

Building Custom MCP Servers for Internal Tools

Every enterprise has proprietary internal tools — homegrown deployment systems, custom CRMs, internal knowledge bases — that don't have pre-built MCP servers. Building a custom server is more accessible than most engineers expect: a basic read-only MCP server for a REST API is typically 50-100 lines of Python or TypeScript.

The core pattern for a custom server in Python using the MCP SDK:

from mcp.server import Server
from mcp.server.stdio import stdio_server
import mcp.types as types

server = Server("internal-docs")

@server.list_tools()
async def list_tools():
    return [types.Tool(
        name="search_docs",
        description="Search internal documentation",
        inputSchema={"type": "object", "properties": {
            "query": {"type": "string", "description": "Search query"}
        }, "required": ["query"]}
    )]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "search_docs":
        results = your_docs_api.search(arguments["query"])
        return [types.TextContent(type="text", text=str(results))]

async def main():
    async with stdio_server() as (read, write):
        await server.run(read, write, server.create_initialization_options())
    

For write-capable servers (those that can create tickets, send messages, or modify data), invest time in implementing an approval workflow: Claude proposes the action and describes what it will do, the user confirms, then the MCP server executes. This "human-in-the-loop" pattern is best practice for any MCP tool that modifies data and builds user trust in the integration.

Enterprise Security Patterns

MCP security is not an afterthought — it's a design decision. The most important principles from our enterprise deployments:

Least privilege per server. A Confluence MCP server should have read-only access to specific spaces, not admin access to your entire Atlassian org. Define the minimum necessary permissions at the service account level before writing any configuration.

Audit all tool calls. Implement logging at the MCP server level that records: timestamp, user, tool called, arguments, and response summary. This is your forensic record if you need to understand what Claude accessed or modified. For regulated industries (healthcare, finance, legal), this logging is not optional.

Network segmentation. MCP servers should run inside your network perimeter, never exposed directly to the internet. If you're deploying centralised MCP servers for team use, they should be accessible only through your VPN or internal network, with TLS termination at the edge.

Regular credential rotation. MCP server tokens should rotate on a schedule (quarterly is typical for most enterprises). Build your credential management to support rotation without service disruption — use a secrets manager like Vault or AWS Secrets Manager rather than hardcoded credentials.

Teams that get MCP security right report that it's actually easier to govern than individual user API access to the same systems, because all Claude-originated actions flow through a small number of service accounts with consistent logging, rather than being scattered across individual users' direct API usage.

Rolling Out MCP Across Engineering Teams

The deployment pattern that works best in engineering organisations: start with a pilot group of 5-10 engineers who are already heavy Claude users. Give them a curated MCP configuration for your core engineering tools (GitHub, Jira, your docs system). Run for two weeks, collect feedback on which tools they actually use and which prompts work best. Then document the "starter pack" configuration and prompt library, and use that validated package for the wider team rollout.

The most important cultural element: make it clear what Claude with MCP can and cannot do. Engineers who understand the tool boundaries use it more effectively and with better security hygiene than engineers who have to discover the limits through experimentation. Our Claude Training service includes role-specific MCP onboarding sessions that typically reduce time-to-productivity from 2 weeks to 2 days.

For the broader engineering organisation, the natural expansion path is: core dev tools → deployment/infrastructure tools → internal platform APIs → cross-functional tools (connecting engineering MCP access to product management and customer support systems). Each expansion phase should go through the same scoping, security review, and pilot process as the initial deployment.

Teams using Claude with comprehensive MCP integration consistently report the most dramatic productivity numbers in our portfolio: the SaaS Engineering Velocity case study documents a 47% reduction in time-to-PR-merge when Claude was connected to the full engineering toolchain via MCP. See also our Engineering department guide and the MCP enterprise white paper for deeper architectural guidance.

MCP Servers Setup Guide for Enterprise: Connect Claude to Everything