What is MCP, and what does it change for Claude Code?
Connecting Claude Code to enterprise systems almost always means plugging in MCP servers. With no connector installed, the agent works on the files in the folder you open and runs the commands you allow. Once a connector is added, it can read a ticket, query a database or post a message, with the permissions of whichever account authorised it.
The Model Context Protocol (MCP) is an open standard that Anthropic released in November 2024 to link AI applications to external systems. Each link runs through an MCP server, also called a connector, which exposes to the model actions it can execute, data it can read and reusable instruction templates.
The introductory lesson of the MCP module at Koneetiv Academy compares the protocol to a USB plug, and the protocol’s official site describes a USB-C port for AI applications: one format, and every tool connects the same way. Since December 2025 the protocol has been held by the Agentic AI Foundation, a fund under the Linux Foundation, so its governance no longer depends on a single vendor. For a company, though, the plug analogy hides the main point: a connector also carries permissions, which need settling before anything gets plugged in.
Tools, resources, prompts: what a server exposes
The MCP specification (28 July 2026 revision) sorts what a server can offer by who triggers it. Prompts are chosen by the user, and Claude Code lists them as commands you type after a slash. Resources are data the application attaches to the context: in Claude Code you reference them with an @ mention, like a file. Tools are called by the model itself, whenever it decides an action is useful.
Tools deserve the most attention, because the model decides when to call them. When a developer types “open a ticket for this bug”, Claude finds the create action in the ticketing connector, fills in the fields and runs it, subject to the permissions in place. The connector therefore sets the boundary of what the agent can do, far more than the prompt does.
From the developer’s laptop to the enterprise stack
The course examples use email, calendars and Figma mockups because anyone can try them without asking IT. In a company, the connectors that matter touch core systems, all the way to the CRM. Teams can also write their own MCP server to expose an in-house API, and that is often where IT finds the most value, on data no vendor will ever connect for them. MCP is an API-based route, the option we weighed against screen automation in our analysis of computer use versus API integration for AI agents.
How do you connect an MCP server to Claude Code?
The claude mcp add command registers a server, and /mcp, inside a session, shows the status of each connection and starts authentication when it is needed. Two decisions get made at that moment, often without anyone noticing: the transport and the scope of the configuration.
Local or remote: choosing the transport
A local server runs as a process on the developer’s machine and talks to Claude Code over standard input and output (stdio). A remote server is reached over HTTP, the transport that Claude Code’s documentation recommends for online services. The older SSE transport still works, although it is deprecated. For IT, the difference goes beyond plumbing: a remote server is governed in one place, while a local one lives on every laptop, with its own dependencies and updates.
Local, project, user: where the configuration lives
Claude Code files each server under a scope. Local scope, the default, keeps the server private and limited to the current project, in the user’s ~/.claude.json file. User scope makes it available across all of that person’s projects, stored in the same file. Project scope writes it to a .mcp.json file at the repository root, meant to be committed, so the whole team inherits the same connectors.
In an interactive session, Claude Code asks for approval before using a server declared in .mcp.json. In non-interactive runs (claude -p, the Agent SDK, cloud sessions), it loads those servers without asking. A repository cloned into a CI pipeline therefore brings its connectors along, with nobody there to confirm anything. In a CI pipeline or a claude -p script, the --strict-mcp-config flag limits the session to the servers passed with --mcp-config, but Claude Code exits at startup if a managed-mcp.json file is deployed on the machine. The allowedMcpServers allowlist, described below, filters those servers too, and the flag does not bypass it.
Authenticating without leaking secrets
Many remote servers use OAuth 2.0: the user signs in once in the browser from /mcp, and Claude Code keeps the token. For servers that take an API key, .mcp.json can read environment variables written as ${VARIABLE_NAME}, so the configuration can be committed without the key in it. Organisations running Kerberos, short-lived tokens or an internal SSO get a dedicated setting, headersHelper, which generates authentication headers at connection time.
Which enterprise systems should you connect first?
Start with systems your Claude Code users already read and are entitled to see: the ticketing tool, internal documentation, the code repository, monitoring. Connectors that write to a system of record, such as the CRM, the ERP or payroll, come later, once permissions, OAuth scopes and logging are in place.
The sequence we recommend for a first rollout:
- List the tasks where developers currently copy information from a tool into Claude Code by hand.
- Pick, for each one, the vendor’s official server or an internal server reviewed by the security team.
- Open read access first, with an account or scopes limited to that need.
- Watch real usage over a trial period, then decide on write tools one at a time.
Support and operations: diagnosing without switching tools
A typical case, as an illustration: an operations engineer picks up an incident. With one connector to the ticketing tool and another to monitoring, Claude Code reads the ticket, pulls the error logs for the relevant window, ties the error back to the code in the repository and proposes a fix. Nothing is written outside the repository, and the engineer reviews the change before submitting it.
Data: writing queries against the real tables
An analyst drafting a query is better off letting Claude Code read the warehouse schema than pasting it in. The connector should then point to a read-only account, on a replica or a staging environment where possible. Claude Code’s documentation sets a warning above 10,000 tokens per tool result and a default cap of 25,000 tokens, beyond which the result is written to a file: bounding queries in the connector itself avoids that detour.
CRM and business applications: wait until the framework is in place
Connecting a CRM opens customer data, much of it personal data under the GDPR, to an agent that can also write. We covered the questions to settle in our piece on Salesforce in Claude and what a CIO should check before the beta: where the data flows, which profiles to open, who approves writes. The same questions apply to any connector plugged into a system of record.
What security risks does an MCP connector create?
A connector gives Claude real access, with the permissions of the account that authorised it. Anthropic says so in its documentation on controlling MCP servers: it reviews connectors against its listing criteria before adding them to the Anthropic Directory, but it does not security-audit or manage any MCP server. Responsibility for what gets connected sits with the company.
Prompt injection through data
A server that fetches external content, such as a web page, an email or a ticket written by a customer, can carry hidden instructions. Claude Code’s documentation is explicit: verify you trust each server before connecting it, because servers that fetch external content can expose you to prompt injection. The risk grows when the same agent reads untrusted content and also holds write tools. That combination is the first one to break up, by separating use cases or by requiring human approval for writes.
What the token is allowed to do
A connector acts with the token it was given. If that token opens an administrator’s entire account, the agent inherits all of it. Claude Code lets you pin the OAuth scopes a server requests (the oauth.scopes setting), and its documentation describes this as the supported way to restrict a server to a subset approved by the security team. On the server side, the security best practices published on modelcontextprotocol.io forbid accepting any token that was not issued to the server itself, and recommend minimal scopes that are widened case by case.
Local servers and where they come from
A local server is a program running on the laptop with the user’s rights. Installed from a public repository without review, it carries the same risks as any software package: malicious code, a compromised dependency, an update that changes behaviour. The protocol’s best practices treat local server compromise as a threat in its own right. We recommend that no local server goes live until it has been reviewed, pinned to a version and listed in the internal catalogue.
How can IT stay in control of connectors?
By default, anyone running Claude Code can connect any MCP server they choose. According to Deloitte (State of AI in the Enterprise, 2026 edition), only 21% of organisations have a mature governance model for their AI agents. Connectors are a sensible place to start, because Claude Code already provides the controls and they roll out like any other endpoint policy.
An approved catalogue instead of an after-the-fact inventory
Claude Code reads managed settings deployed by administrators, which take priority over user settings. A managed-mcp.json file, pushed through device management (Jamf, Intune, Group Policy), fixes the server list: users can no longer add their own, and an empty file shuts everything off except servers the administrator provides through managedMcpServers and those built into the host application. For a lighter touch, allowedMcpServers and deniedMcpServers filter what users configure, preferably by command or URL: a name filter is easy to get around, since users can give a server any name they like. An allowlist only becomes authoritative with the allowManagedMcpServersOnly lock: without it, users can widen it from their own settings.
With no built-in store to browse, the documentation suggests publishing the approved list on an internal wiki, or distributing servers as plugins through a company-managed marketplace.
Permissions tool by tool
Claude Code permission rules also cover MCP tools, written as mcp__server__tool. You can let a server’s read tools run without confirmation, keep writes behind an approval prompt and deny everything else. A single deny rule on mcp__* removes every MCP tool at once. For connectors managed from claude.ai, the organisation can set a tool to “ask”, which forces a confirmation on every call even in the most permissive modes, or to “blocked”, which removes it from the list.
Knowing what is actually used
When OpenTelemetry export is configured, Claude Code can record which MCP servers and tools people call, by setting OTEL_LOG_TOOL_DETAILS=1. That gives you the basis for a regular review of which connectors are really used and which ones write to a system of record. Our approach to AI agent governance starts from that kind of evidence, and our framework for classifying AI agents by trust zone helps decide which write tools to open, and under what human oversight.
Connectors from claude.ai inside Claude Code
When a user signs in to Claude Code with a claude.ai subscription, the connectors on their account, which admins add on Team and Enterprise plans, also show up in Claude Code. That does not happen with an API key, or through a cloud provider such as Amazon Bedrock. Your connector policy has to cover both entry points at once.
Which mistakes should you avoid early on?
Committing an API key in .mcp.json
The .mcp.json file is built to be shared, which means read by the whole team and occasionally pushed to a public repository by mistake. A key written in plain text there will leak sooner or later. The ${VARIABLE} syntax exists for exactly that, and Claude Code’s documentation likewise advises against putting credentials in managed-mcp.json, which every user on the machine can read.
Connecting everything available
Each server adds tools the model has to know about. Claude Code keeps that cost down with tool search, on by default: only tool names and server instructions load at startup, and full definitions are fetched on demand. Tool search settles the context question. The risk question stays open, because every available tool is an action the agent may decide to take, and an unused connector is still attack surface.
How can you learn MCP with Claude Code?
This article builds on the “MCP & connectors” module of the Claude Code track at Koneetiv Academy. The module covers the basics step by step: what an MCP server is, how tools, resources and prompts differ, then installing a first connector and the security habits that go with it. Each lesson ends with validation questions. The course is taught in French for now, with an English version on the way, and the trial lesson can be taken without creating an account.
Who it is for, and in what order
Like the rest of the Academy, the module is designed for non-developers: no programming language is required. For a team rolling out Claude Code together, developers included, we suggest taking the module before opening the first shared connector, so the questions in this guide land on a common vocabulary. When a connector stops responding, our Claude Code troubleshooting guide covers that case, and the AI glossary defines the terms used here.
Scaling up across the organisation
Training users does not settle the IT side. Our page on Claude Code for enterprises describes how we support these rollouts as an official Anthropic partner. And to see where your organisation stands before starting, the AI maturity assessment scores it across the six axes of the Koneetiv framework (2026 edition), governance included.