Making Context Portable: MCP, Prompts, Skills, and Sessions
CC Switch does not stop at provider credentials: it also manages the tools, instructions, files, and history that make an AI workflow useful. This chapter examines how MCP servers, prompts, skills, sessions, and OpenClaw workspace files move from managed state into different clients, and what each artifact's ownership rules allow. The practical outcome is a more careful idea of portability—one that preserves native differences and identifies where a copied configuration is not yet a working or trustworthy workflow.
Different artifacts, different ownership rules
The first mistake in discussing portability is to treat every piece of context as a file to copy. An MCP server is a connection definition that may launch a process or contact a remote endpoint. A prompt is text that a client loads as instruction. A skill is a folder whose contents may include tool definitions and other files. A session is a record of past interaction. These artifacts have different lifecycles, security implications, and native formats, so CC Switch gives them related but separate management paths.
MCP—the Model Context Protocol—lets an AI tool reach capabilities outside the model itself. A server might expose file access, a database query, a web fetch, or another API. CC Switch stores a server definition centrally with an identifier, description, transport details, and per-application enablement. The transport can be standard input/output, where the client launches a local command, or a network transport such as HTTP or server-sent events. The choice determines what crosses the boundary: a local process command and its environment are one kind of dependency; a URL and request headers are another.
When a user enables an MCP server for an application, CC Switch updates the managed enablement state and projects the server into that application's native configuration. Claude and Gemini use JSON-shaped server maps, while Codex uses TOML. OpenCode and Hermes have their own locations and layouts. The central record stays conceptually the same, but the projected representation follows the client. This is controlled translation, not a promise that one native file can be used everywhere.
That projection is conditional on the application being present. If the corresponding client directory or configuration is not found, CC Switch can retain the enablement choice without writing a nonexistent installation. This makes the central record useful for a later installation, but it also creates an important distinction between “enabled in CC Switch” and “loaded by the client.” The client must exist, the native file must be written, and the client must reach the point at which it reads that file.
The support boundary is also explicit. The current implementation skips MCP synchronization for Claude Desktop profiles and for OpenClaw, whose MCP support is still under development. The English manual is versioned earlier than the current checkout and lists a smaller supported set, so a reader should consult the installed release for the authoritative app behavior. The important architectural point is not a fixed count. It is that an enablement record can exist even where no projection is currently available.
MCP definitions are more sensitive than ordinary preferences because they can carry executable behavior. A standard-I/O definition names a command, arguments, and environment variables; an HTTP or SSE definition can carry a URL and headers. CC Switch's interface can centralize and project those values, but centralization does not make the command safe, the remote server trustworthy, or a secret suitable for sharing. A user should review what an imported or shared MCP definition will launch or contact before enabling it.
Prompts follow a different ownership rule.