MCP Protocol Enterprise Guide: Building Secure Claude Tool Integrations

What Is MCP and Why It Matters for Enterprise

Model Context Protocol is an open standard, developed by Anthropic, that defines how AI models connect to external data sources and tools. Before MCP, connecting Claude to your Salesforce CRM required a custom integration built from scratch — unique to every deployment, hard to maintain, and impossible to share. MCP standardises the integration layer: any tool that exposes an MCP server can be used by Claude (or any MCP-compatible AI) through a consistent interface.

For enterprise architects, MCP is the equivalent of what REST APIs did for web services. It creates a composable integration ecosystem where tool capabilities can be developed once, secured once, and reused across multiple AI contexts. A Jira MCP server built for Claude in your IDE can also serve Claude in your Cowork environment. The security controls are defined in one place.

The practical significance for enterprises: Claude with the right MCP servers can perform tasks that require real-time data and system interaction without any custom prompt engineering per-task. An analyst asking "What are our top 10 customers by revenue this quarter?" gets an answer from your CRM. A developer asking "Create a Jira ticket for the bug we just discussed" gets the ticket created. This is the difference between Claude as a productivity tool and Claude as a workflow automation layer.

Our MCP Protocol product guide covers the full feature set and official documentation. This guide focuses on enterprise deployment — security, architecture, and production operations.

MCP Architecture: How It Works

MCP has three components: the MCP client (the AI model, or the application embedding it), the MCP server (your integration layer), and the resource or tool being accessed (your database, API, or file system). The client and server communicate over a defined protocol — either local stdio (for desktop tools like Claude Cowork and Claude Code) or HTTP with server-sent events (for remote deployments).

An MCP server exposes three types of capabilities to Claude. Tools are executable functions — create a ticket, send a query, update a record. Resources are data sources that Claude can read — documents, database records, file contents. Prompts are reusable prompt templates that can be invoked by name. For most enterprise integrations, tools and resources are the relevant primitives.

When Claude decides it needs to use a tool, it calls the MCP server with the tool name and parameters. The server validates the request, executes it against the underlying system, and returns the result. Claude incorporates the result into its context and continues reasoning. The human sees only Claude's response — the MCP interaction is transparent.

Types of MCP Servers: What to Build First

The right MCP servers to build first depend on which systems your Claude deployment needs to access. These are the most common enterprise integrations and their typical use cases.

MCP Security: Authentication, Authorisation & Least Privilege

MCP security is the most important topic in enterprise MCP deployment, and the one most often underinvested. An MCP server is a privileged access layer — it can read and write to your production systems on behalf of Claude. Getting the security model wrong creates significant risk.

Authentication

Every MCP server must authenticate Claude clients before serving any requests. For remote MCP servers (HTTP transport), implement OAuth 2.0 or API key authentication. The client (Claude API integration, Cowork instance, or Code environment) must present a valid credential before the server accepts any requests. Never deploy an MCP server accessible without authentication, even on internal networks.

For user-specific access (where the tools should act on behalf of the logged-in user rather than a service account), implement OAuth 2.0 with user token forwarding. This ensures that when a sales rep uses Claude to query CRM data, they see only the records they're authorised to see — not the entire database.

Principle of Least Privilege

Every MCP server should expose only the minimum set of tools and data access required for its use case. A database MCP server for a finance reporting use case should have read-only access to finance tables only — not write access, not access to HR data, not access to production operational tables. Design your MCP server's permission scope before implementation, not after.

Separate write-capable servers from read-only servers architecturally. Read-only MCP servers have a significantly smaller risk surface — the worst case is data exposure, not data modification. Write-capable servers (those that can create tickets, update records, send messages) require additional controls: action logging, rate limiting, and in some cases a human confirmation step before execution.

Tool Definitions and Input Validation

Every tool definition in your MCP server must include strict input schemas. Claude passes tool parameters based on its interpretation of user intent — without input validation, a malformed or adversarially crafted input could cause unexpected behaviour in your underlying system. Validate every parameter type, range, and format before execution. Log the raw input for audit purposes.

{
  "name": "query_finance_data",
  "description": "Query the finance data warehouse for reporting data",
  "inputSchema": {
    "type": "object",
    "properties": {
      "metric": {
        "type": "string",
        "enum": ["revenue", "opex", "headcount", "ebitda"],
        "description": "The financial metric to query"
      },
      "period": {
        "type": "string",
        "pattern": "^\\d{4}-Q[1-4]$",
        "description": "Period in format YYYY-QN"
      },
      "entity": {
        "type": "string",
        "maxLength": 50
      }
    },
    "required": ["metric", "period"]
  }
}

Building an Enterprise MCP Server: The Key Decisions

Before writing any code for an enterprise MCP server, these architectural decisions need to be made. Getting them right saves significant rework.

Transport: stdio vs. HTTP

stdio transport (local process communication) is appropriate for MCP servers running on the user's local machine — the standard deployment model for Claude Cowork and Claude Code. The server process runs on the user's computer and communicates over stdin/stdout. HTTP/SSE transport is appropriate for centralised enterprise deployments where the MCP server is a shared service — accessing a central database, CRM, or API on behalf of multiple users. For enterprise deployments where you need centralised access controls and auditing, HTTP transport is usually the right choice.

Stateless vs. Stateful

Design MCP servers to be stateless wherever possible. Stateless servers scale horizontally, simplify failure recovery, and eliminate session management complexity. For servers that need to maintain context across tool calls within a single Claude session (rare), implement state in a distributed cache (Redis) with session IDs rather than in-process.

Tool Granularity

Each tool should do one well-defined thing. Avoid tools with complex branching logic or tools that conditionally do different things based on input. Claude's tool selection is based on tool descriptions — ambiguous tools with multiple behaviours are selected inappropriately and produce unexpected results. One tool per atomic operation.

Error Handling

Design your error responses carefully. Claude uses the error message content to decide how to respond to the user and whether to retry. Error messages should be descriptive enough for Claude to give the user useful guidance, but should not expose sensitive internal details (stack traces, database schemas, internal service names).

Production Deployment and Operations

Deploying MCP servers to production requires the same operational standards as any other production service. The key operational areas are monitoring, access management, and change control.

Monitoring and Alerting

Instrument every MCP server with structured logging: log every tool call with user identity, tool name, input parameters, execution time, result status, and the downstream system called. Aggregate logs in your central SIEM or logging platform. Alert on: unusual call volumes (potential abuse), authentication failures (potential credential compromise), downstream system errors above a threshold, and tool calls to restricted operations. This monitoring infrastructure is also the audit trail you'll need for compliance review.

Access Management Lifecycle

MCP server access should be managed as a privileged access right, not a general user right. Implement quarterly access reviews. When users change roles or leave the organisation, revoke MCP server credentials as part of the offboarding process. For high-privilege MCP servers (those with write access to production systems), implement time-bound access tokens rather than static credentials.

Change Control

Changes to MCP tool definitions — adding tools, modifying schemas, changing permission scopes — should go through your standard change control process. A tool definition change can significantly alter Claude's behaviour in the tools it selects and how it uses them. Test changes in a staging environment against representative Claude interactions before deploying to production.

Common Enterprise Integrations

The most common enterprise MCP integrations and the relevant considerations for each. Our MCP Servers for Salesforce, Jira, and Slack guide covers these in greater technical depth.

Salesforce MCP Integration

Use the Salesforce REST API or Metadata API as the backend for your Salesforce MCP server. Implement OAuth 2.0 with user token forwarding so Claude respects Salesforce's native record-level security. Key tools to expose: account lookup, opportunity query, contact search, activity log, and — for appropriate users — record creation and update. Do not expose bulk delete or configuration management operations through MCP.

PostgreSQL / Database MCP Integration

Start with a read-only database user that has access only to the specific schemas required. Build query tools that accept structured parameters and construct parameterised SQL — never pass raw SQL from Claude to your database. Implement a query complexity limit to prevent expensive queries that could impact production performance. Our Claude Database MCP tutorial includes a complete implementation example.

Jira MCP Integration

Use Jira's REST API. For read operations (search issues, view project details), use a service account with read-only permissions. For write operations (create issue, add comment, transition status), implement user token forwarding so actions are attributed to the actual user in Jira's audit log. This is important for compliance in organisations where Jira is used for change management processes.

Internal APIs

Wrapping internal microservices as MCP tools is the most flexible pattern and often the highest-value one. Build a thin MCP adapter layer in front of your internal API — don't modify your internal APIs to support MCP. The adapter handles authentication, input validation, and schema mapping. This keeps your MCP layer thin and your internal services unchanged.

Related Articles