MCP: When the Plugin Reaches Outside the Session

Model Context Protocol, or MCP, is the point where a Claude Code plugin can expose a structured tool backed by a local process or an outside service. This chapter follows that boundary through transport, authentication, tool naming, permission scope, and returned data. The practical goal is to choose and evaluate an MCP integration without confusing “the plugin is installed” with “the remote system is trusted, available, or authorized to do everything the user can do.”

The local extension surfaces described earlier mainly shape context, invoke workflows, delegate analysis, or react to events. MCP adds another participant. A tool call can leave the Claude Code session, cross a network or process boundary, reach a service that owns its own state, and return data for the model to use. That can make a plugin much more useful, but it changes who owns the action, where credentials are held, how failures appear, and what the user must inspect.

Four transports, four boundary shapes

The plugin-development guidance describes four MCP server types. The names are less important than the boundary each one creates.

Stdio starts a local MCP server as a child process and communicates through standard input and output. This is suited to a local tool, a database connection on the user’s machine, or a custom server bundled with the plugin. Claude Code manages the process lifecycle. The data may stay on the machine, but “local” does not automatically mean harmless: the process can read files, use environment variables, launch dependencies, or access a database under the user’s permissions.

Server-Sent Events, or SSE, connects to a hosted server and is presented in the guidance as a fit for cloud services and OAuth-based authentication. The connection is remote, so the endpoint operator becomes part of the trust boundary. OAuth can reduce the need to place a long-lived token directly in a configuration file, but consent still grants a scope of access and the service still receives requests and results.

HTTP connects to an MCP endpoint through a REST-style request path, commonly with a token in a header. This can be a useful shape for a stateless API backend or a hosted MCP server. It also makes the data path explicit: the URL, headers, request payload, and response all cross the network. A token stored in an environment variable is better than a hard-coded token, but the endpoint and token scope still require review.

WebSocket supports a persistent, bidirectional connection for real-time or streaming use cases. It can make sense when a service needs low-latency updates or push notifications. The persistence changes the operational questions: when does the connection begin, how long does it remain active, how are reconnects handled, and what data can arrive without a new user command? The repository’s guidance recommends secure WSS rather than an insecure WebSocket connection for this reason.

The MCP server development plugin adds a design layer above these transports.