Claude Code MCP Integration
Configure external MCP services and tools for Claude Code plugins.
The material recommends environment variables, HTTPS/WSS, narrowly scoped allowed-tools, and avoiding hardcoded credentials. However, data flows, permission boundaries, user confirmation, revocation, and rollback are incomplete; agents are described as having autonomous access to all MCP tools, so points are deducted.
Examples, lifecycle notes, error handling, and testing checklists cover common paths. Static files contain no executable tests, and lifecycle claims conflict between on-demand connection and startup-on-enable; several transport and configuration behaviors remain unverified, so the score is constrained and reduced.
The name, trigger phrases, and MCP use cases are clear, covering stdio, SSE, HTTP, and WebSocket. Non-fit boundaries, compatibility expectations, and trigger precision are insufficiently evidenced; the documentation is English-only and core cloud scenarios depend on overseas services that may be unreachable from mainland China.
The documentation is reasonably layered and includes references, examples, troubleshooting, and an implementation workflow. It has only version 0.1.0, no changelog, explicit maintenance owner, or update path; the supplied license metadata is unknown and setup assumptions rely partly on external README material.
The skill offers directly reusable configuration snippets, naming guidance, security practices, and troubleshooting steps for the core MCP integration task. However, representative outputs are not verified in the files, and service availability and platform behavior require substantial manual checking, so it does not receive the static maximum.
The supplied files are auditable and include examples, checklists, and test instructions. They provide no committed test suite, CI coverage, or third-party execution evidence for key paths; important claims remain documentation assertions, so only limited static verifiability is awarded.
- Treat the agent claim of access to all MCP tools as a high-privilege design; restrict tools before publication and require explicit confirmation plus recovery plans for external writes and destructive operations.
- Verify that the target Claude Code version actually supports the documented SSE, HTTP, WebSocket, headersHelper, lifecycle, and tool-naming behavior.
- Cloud examples depend on overseas domains; mainland-China users may encounter reachability, OAuth callback, or regional-service limitations.
- Ensure debug logs, environment variables, and error output never expose tokens or other sensitive data.
What it does & when to use it
This skill guides developers through integrating Model Context Protocol (MCP) servers with Claude Code plugins. It covers stdio, SSE, HTTP, and WebSocket transports, along with OAuth, token, and environment-variable authentication patterns. It explains how to configure servers through .mcp.json or plugin.json, allow MCP tools in commands, and test, debug, and handle failures locally. It fits Claude Code users building plugins that connect to databases, APIs, file systems, or hosted services.
It instructs users to create .mcp.json at a plugin root or add an mcpServers field to plugin.json; configure command, args, env, url, and headers; use ${CLAUDE_PLUGIN_ROOT} and user environment variables; select stdio, SSE, HTTP, or WebSocket based on the server; pre-allow specific MCP tools in command frontmatter; inspect servers with /mcp; and use claude --debug to investigate connections, tool discovery, authentication, and tool-call errors. It also supplies handling guidance and validation checklists for connection, tool, and configuration failures.
- A plugin developer needs local database, file-system, or custom-server access and configures a local process over stdio.
- A team wants to connect a plugin to hosted services such as Asana or GitHub with browser-based OAuth through SSE.
- A plugin must call a REST-based MCP backend using Bearer tokens or custom request headers over HTTP.
- A workflow needs real-time streaming, push notifications, or low-latency bidirectional communication through WebSocket.
- A developer maintains a plugin spanning several external services and needs to restrict commands to only the required MCP tools.
Pros & cons
- Covers four connection approaches: local processes, hosted services, REST-based MCP backends, and real-time WebSocket servers.
- Includes OAuth, environment-variable tokens, tool naming, permission scoping, error handling, and debugging guidance.
- Provides an end-to-end workflow from configuration and local testing through publication-oriented documentation.
- It is built around Claude Code plugin mechanisms, including .mcp.json, plugin.json, /mcp, and claude --debug, so it is not directly platform-neutral.
- The source provides no standalone installation procedure, test suite, or complete verifiable example project.
- It does not specify licensing, pricing, or exact compatibility versions for MCP servers.
How to install
The source does not provide a standalone installation command for this individual skill. It is located at plugins/plugin-dev/skills/mcp-integration/SKILL.md in the Claude Code repository. The repository README explains how to install Claude Code and run claude in a project directory, but does not document separate installation or enablement for this skill.
How to use
In Claude Code, ask for tasks such as “add MCP server,” “integrate MCP,” “configure MCP in plugin,” or “use .mcp.json.” Then create .mcp.json at the plugin root, choose stdio, SSE, HTTP, or ws configuration, document required environment variables, pre-allow specific mcp__plugin_... tools in relevant commands, inspect the server with /mcp, and use claude --debug for troubleshooting.