MCP Integration
AnthropicOfficialPublished by Anthropic
- Skill
- Tool integration
- Automation and integrations
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured approach to connecting external services, databases, and APIs to Claude Code plugins using the Model Context Protocol (MCP). It covers configuration methods, supported transport types (stdio, SSE, HTTP, WebSocket), authentication patterns including OAuth, and best practices for secure and efficient tool integration.
What it does
- Explains how to configure MCP servers via .mcp.json or plugin.json files.
- Details transport types for local processes (stdio) and cloud services (SSE, HTTP, WebSocket).
- Provides patterns for handling OAuth and token-based authentication.
- Outlines environment variable expansion for portable plugin configurations.
- Defines naming conventions and security scoping for MCP tools.
- Offers debugging and testing strategies for MCP-enabled plugins.
When to use it
- When you need to expose external service capabilities as tools within a Claude Code plugin.
- When integrating local databases or file systems via stdio servers.
- When connecting to cloud-hosted services that provide MCP endpoints.
- When you need to manage complex authentication flows like OAuth for external tools.
- When you want to bundle multiple MCP servers into a single plugin.
Advantages
- Standardized approach to external service integration.
- Supports both local and remote service architectures.
- Automated handling of OAuth flows for cloud services.
- Secure token management via environment variables.
- Clear separation of concerns for plugin configuration.
Usage examples
- “How do I add an MCP server to my plugin?”
- The agent will guide you to create a .mcp.json file at the plugin root, define the server type (stdio, SSE, etc.), and configure the necessary command or URL using ${CLAUDE_PLUGIN_ROOT}.
- “How do I connect to a hosted MCP service using OAuth?”
- The agent will explain how to configure an SSE-type server in your configuration, noting that Claude Code will automatically trigger the browser-based OAuth flow upon first use.
- “What is the best way to secure my API tokens in an MCP configuration?”
- The agent will advise using environment variables (e.g., ${API_TOKEN}) within your configuration file and documenting the required variables in your plugin's README, rather than hardcoding them.
- “How do I restrict which tools an MCP server can access?”
- The agent will show you how to use the allowed-tools field in your command frontmatter to explicitly list only the necessary MCP tools, avoiding the use of wildcards.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/anthropics/mcp-integration/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip mcp-integration.zip -d .agents/skills
Documentation by Anthropic
MCP Integration for Claude Code Plugins
Overview
Model Context Protocol (MCP) enables Claude Code plugins to integrate with external services and APIs by providing structured tool access. Use MCP integration to expose external service capabilities as tools within Claude Code.
Key capabilities:
Connect to external services (databases, APIs, file systems)
Provide 10+ related tools from a single service
Handle OAuth and complex authentication flows
Bundle MCP servers with plugins for automatic setup
MCP Server Configuration Methods
Plugins can bundle MCP servers in two ways:
Method 1: Dedicated .mcp.json (Recommended)
Create .mcp.json at plugin root:
{
"database-tools": {
"command": "${CLAUDE_PLUGIN_ROOT}/servers/db-server",
"args": ["--config", "${CLAUDE_PLUGIN_ROOT}/config.json"],
"env": {
"DB_URL": "${DB_URL}"
}
}
}Benefits:
Clear separation of concerns
Easier to maintain
Better for multiple servers
Method 2: Inline in plugin.json
Add mcpServers field to plugin.json:
{
"name": "my-plugin",
"version": "1.0.0",
"mcpServers": {
"plugin-api": {
"command": "${CLAUDE_PLUGIN_ROOT}/servers/api-server",
"args": ["--port", "8080"]
}
}
}Benefits:
Single configuration file
Good for simple single-server plugins
MCP Server Types
stdio (Local Process)
Execute local MCP servers as child processes. Best for local tools and custom servers.
Configuration:
{
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/allowed/path"],
"env": {
"LOG_LEVEL": "debug"
}
}
}Use cases:
File system access
Local database connections
Custom MCP servers
NPM-packaged MCP servers
Process management:
Claude Code spawns and manages the process
Communicates via stdin/stdout
Terminates when Claude Code exits
SSE (Server-Sent Events)
Connect to hosted MCP servers with OAuth support. Best for cloud services.
Configuration:
{
"hosted-service": {
"type": "sse",
"url": "https://mcp.example.com/sse"
}
}Use cases:
Official hosted MCP servers (Asana, GitHub, etc.)
Cloud services with MCP endpoints
OAuth-based authentication
No local installation needed
Authentication:
OAuth flows handled automatically
User prompted on first use
Tokens managed by Claude Code
HTTP (REST API)
Connect to RESTful MCP servers with token authentication.
Configuration:
{
"api-service": {
"type": "http",
"url": "https://api.example.com/mcp",
"headers": {
"Authorization": "Bearer ${API_TOKEN}",
"X-Custom-Header": "value"
}
}
}Use cases:
REST API-based MCP servers
Token-based authentication
Custom API backends
Stateless interactions
WebSocket (Real-time)
Connect to WebSocket MCP servers for real-time bidirectional communication.
Configuration:
{
"realtime-service": {
"type": "ws",
"url": "wss://mcp.example.com/ws",
"headers": {
"Authorization": "Bearer ${TOKEN}"
}
}
}Use cases:
Real-time data streaming
Persistent connections
Push notifications from server
Low-latency requirements
Environment Variable Expansion
All MCP configurations support environment variable substitution:
${CLAUDE_PLUGIN_ROOT} - Plugin directory (always use for portability):
{
"command": "${CLAUDE_PLUGIN_ROOT}/servers/my-server"
}User environment variables - From user's shell:
{
"env": {
"API_KEY": "${MY_API_KEY}",
"DATABASE_URL": "${DB_URL}"
}
}Best practice: Document all required environment variables in plugin README.
MCP Tool Naming
When MCP servers provide tools, they're automatically prefixed:
Format: mcp__plugin_<plugin-name>_<server-name>__<tool-name>
Example:
Plugin:
asanaServer:
asanaTool:
create_taskFull name:
mcp__plugin_asana_asana__asana_create_task
Using MCP Tools in Commands
Pre-allow specific MCP tools in command frontmatter:
---
allowed-tools: [
"mcp__plugin_asana_asana__asana_create_task",
"mcp__plugin_asana_asana__asana_search_tasks"
]
---Wildcard (use sparingly):
---
allowed-tools: ["mcp__plugin_asana_asana__*"]
---Best practice: Pre-allow specific tools, not wildcards, for security.
Lifecycle Management
Automatic startup:
MCP servers start when plugin enables
Connection established before first tool use
Restart required for configuration changes
Lifecycle:
Plugin loads
MCP configuration parsed
Server process started (stdio) or connection established (SSE/HTTP/WS)
Tools discovered and registered
Tools available as
mcp__plugin_...__...
Viewing servers:
Use /mcp command to see all servers including plugin-provided ones.
Authentication Patterns
OAuth (SSE/HTTP)
OAuth handled automatically by Claude Code:
{
"type": "sse",
"url": "https://mcp.example.com/sse"
}User authenticates in browser on first use. No additional configuration needed.
Token-Based (Headers)
Static or environment variable tokens:
{
"type": "http",
"url": "https://api.example.com",
"headers": {
"Authorization": "Bearer ${API_TOKEN}"
}
}Document required environment variables in README.
Environment Variables (stdio)
Pass configuration to MCP server:
{
"command": "python",
"args": ["-m", "my_mcp_server"],
"env": {
"DATABASE_URL": "${DB_URL}",
"API_KEY": "${API_KEY}",
"LOG_LEVEL": "info"
}
}Integration Patterns
Pattern 1: Simple Tool Wrapper
Commands use MCP tools with user interaction:
# Command: create-item.md
---
allowed-tools: ["mcp__plugin_name_server__create_item"]
---
Steps:
1. Gather item details from user
2. Use mcp__plugin_name_server__create_item
3. Confirm creationUse for: Adding validation or preprocessing before MCP calls.
Pattern 2: Autonomous Agent
Agents use MCP tools autonomously:
# Agent: data-analyzer.md
Analysis Process:
1. Query data via mcp__plugin_db_server__query
2. Process and analyze results
3. Generate insights reportUse for: Multi-step MCP workflows without user interaction.
Pattern 3: Multi-Server Plugin
Integrate multiple MCP servers:
{
"github": {
"type": "sse",
"url": "https://mcp.github.com/sse"
},
"jira": {
"type": "sse",
"url": "https://mcp.jira.com/sse"
}
}Use for: Workflows spanning multiple services.
Security Best Practices
Use HTTPS/WSS
Always use secure connections:
✅ "url": "https://mcp.example.com/sse"
❌ "url": "http://mcp.example.com/sse"Token Management
DO:
✅ Use environment variables for tokens
✅ Document required env vars in README
✅ Let OAuth flow handle authentication
DON'T:
❌ Hardcode tokens in configuration
❌ Commit tokens to git
❌ Share tokens in documentation
Permission Scoping
Pre-allow only necessary MCP tools:
✅ allowed-tools: [
"mcp__plugin_api_server__read_data",
"mcp__plugin_api_server__create_item"
]
❌ allowed-tools: ["mcp__plugin_api_server__*"]Error Handling
Connection Failures
Handle MCP server unavailability:
Provide fallback behavior in commands
Inform user of connection issues
Check server URL and configuration
Tool Call Errors
Handle failed MCP operations:
Validate inputs before calling MCP tools
Provide clear error messages
Check rate limiting and quotas
Configuration Errors
Validate MCP configuration:
Test server connectivity during development
Validate JSON syntax
Check required environment variables
Performance Considerations
Lazy Loading
MCP servers connect on-demand:
Not all servers connect at startup
First tool use triggers connection
Connection pooling managed automatically
Batching
Batch similar requests when possible:
# Good: Single query with filters
tasks = search_tasks(project="X", assignee="me", limit=50)
# Avoid: Many individual queries
for id in task_ids:
task = get_task(id)Testing MCP Integration
Local Testing
Configure MCP server in
.mcp.jsonInstall plugin locally (
.claude-plugin/)Run
/mcpto verify server appearsTest tool calls in commands
Check
claude --debuglogs for connection issues
Validation Checklist
[ ] MCP configuration is valid JSON
[ ] Server URL is correct and accessible
[ ] Required environment variables documented
[ ] Tools appear in
/mcpoutput[ ] Authentication works (OAuth or tokens)
[ ] Tool calls succeed from commands
[ ] Error cases handled gracefully
Debugging
Enable Debug Logging
claude --debugLook for:
MCP server connection attempts
Tool discovery logs
Authentication flows
Tool call errors
Common Issues
Server not connecting:
Check URL is correct
Verify server is running (stdio)
Check network connectivity
Review authentication configuration
Tools not available:
Verify server connected successfully
Check tool names match exactly
Run
/mcpto see available toolsRestart Claude Code after config changes
Authentication failing:
Clear cached auth tokens
Re-authenticate
Check token scopes and permissions
Verify environment variables set
Quick Reference
MCP Server Types
| Type | Transport | Best For | Auth |
|---|---|---|---|
| stdio | Process | Local tools, custom servers | Env vars |
| SSE | HTTP | Hosted services, cloud APIs | OAuth |
| HTTP | REST | API backends, token auth | Tokens |
| ws | WebSocket | Real-time, streaming | Tokens |
Configuration Checklist
[ ] Server type specified (stdio/SSE/HTTP/ws)
[ ] Type-specific fields complete (command or url)
[ ] Authentication configured
[ ] Environment variables documented
[ ] HTTPS/WSS used (not HTTP/WS)
[ ] ${CLAUDE_PLUGIN_ROOT} used for paths
Best Practices
DO:
✅ Use ${CLAUDE_PLUGIN_ROOT} for portable paths
✅ Document required environment variables
✅ Use secure connections (HTTPS/WSS)
✅ Pre-allow specific MCP tools in commands
✅ Test MCP integration before publishing
✅ Handle connection and tool errors gracefully
DON'T:
❌ Hardcode absolute paths
❌ Commit credentials to git
❌ Use HTTP instead of HTTPS
❌ Pre-allow all tools with wildcards
❌ Skip error handling
❌ Forget to document setup
Additional Resources
Reference Files
For detailed information, consult:
references/server-types.md- Deep dive on each server typereferences/authentication.md- Authentication patterns and OAuthreferences/tool-usage.md- Using MCP tools in commands and agents
Example Configurations
Working examples in examples/:
stdio-server.json- Local stdio MCP serversse-server.json- Hosted SSE server with OAuthhttp-server.json- REST API with token auth
External Resources
Official MCP Docs: https://modelcontextprotocol.io/
Claude Code MCP Docs: https://docs.claude.com/en/docs/claude-code/mcp
MCP SDK: @modelcontextprotocol/sdk
Testing: Use
claude --debugand/mcpcommand
Implementation Workflow
To add MCP integration to a plugin:
Choose MCP server type (stdio, SSE, HTTP, ws)
Create
.mcp.jsonat plugin root with configurationUse ${CLAUDE_PLUGIN_ROOT} for all file references
Document required environment variables in README
Test locally with
/mcpcommandPre-allow MCP tools in relevant commands
Handle authentication (OAuth or tokens)
Test error cases (connection failures, auth errors)
Document MCP integration in plugin README
Focus on stdio for custom/local servers, SSE for hosted services with OAuth.
Files
- ATTRIBUTION.mdAdded by AutoGineer968 B
- LICENSELicence file added by AutoGineer11.1 KiB
- SKILL.md12.2 KiB
- examples/http-server.json502 B
- examples/sse-server.json337 B
- examples/stdio-server.json686 B
- references/authentication.md9.9 KiB
- references/server-types.md10.3 KiB
- references/tool-usage.md11.4 KiB
references/authentication.md
MCP Authentication Patterns
Complete guide to authentication methods for MCP servers in Claude Code plugins.
Overview
MCP servers support multiple authentication methods depending on the server type and service requirements. Choose the method that best matches your use case and security requirements.
OAuth (Automatic)
How It Works
Claude Code automatically handles the complete OAuth 2.0 flow for SSE and HTTP servers:
User attempts to use MCP tool
Claude Code detects authentication needed
Opens browser for OAuth consent
User authorizes in browser
Tokens stored securely by Claude Code
Automatic token refresh
Configuration
{
"service": {
"type": "sse",
"url": "https://mcp.example.com/sse"
}
}No additional auth configuration needed! Claude Code handles everything.
Supported Services
Known OAuth-enabled MCP servers:
GitHub (when available)
Google services (when available)
Custom OAuth servers
OAuth Scopes
OAuth scopes are determined by the MCP server. Users see required scopes during the consent flow.
Document required scopes in your README:
## Authentication
This plugin requires the following Asana permissions:
- Read tasks and projects
- Create and update tasks
- Access workspace dataToken Storage
Tokens are stored securely by Claude Code:
Not accessible to plugins
Encrypted at rest
Automatic refresh
Cleared on sign-out
Troubleshooting OAuth
Authentication loop:
Clear cached tokens (sign out and sign in)
Check OAuth redirect URLs
Verify server OAuth configuration
Scope issues:
User may need to re-authorize for new scopes
Check server documentation for required scopes
Token expiration:
Claude Code auto-refreshes
If refresh fails, prompts re-authentication
Token-Based Authentication
Bearer Tokens
Most common for HTTP and WebSocket servers.
Configuration:
{
"api": {
"type": "http",
"url": "https://api.example.com/mcp",
"headers": {
"Authorization": "Bearer ${API_TOKEN}"
}
}
}Environment variable:
export API_TOKEN="your-secret-token-here"API Keys
Alternative to Bearer tokens, often in custom headers.
Configuration:
{
"api": {
"type": "http",
"url": "https://api.example.com/mcp",
"headers": {
"X-API-Key": "${API_KEY}",
"X-API-Secret": "${API_SECRET}"
}
}
}Custom Headers
Services may use custom authentication headers.
Configuration:
{
"service": {
"type": "sse",
"url": "https://mcp.example.com/sse",
"headers": {
"X-Auth-Token": "${AUTH_TOKEN}",
"X-User-ID": "${USER_ID}",
"X-Tenant-ID": "${TENANT_ID}"
}
}
}Documenting Token Requirements
Always document in your README:
## Setup
### Required Environment Variables
Set these environment variables before using the plugin:
\`\`\`bash
export API_TOKEN="your-token-here"
export API_SECRET="your-secret-here"
\`\`\`
### Obtaining Tokens
1. Visit https://api.example.com/tokens
2. Create a new API token
3. Copy the token and secret
4. Set environment variables as shown above
### Token Permissions
The API token needs the following permissions:
- Read access to resources
- Write access for creating items
- Delete access (optional, for cleanup operations)
\`\`\`Environment Variable Authentication (stdio)
Passing Credentials to Server
For stdio servers, pass credentials via environment variables:
{
"database": {
"command": "python",
"args": ["-m", "mcp_server_db"],
"env": {
"DATABASE_URL": "${DATABASE_URL}",
"DB_USER": "${DB_USER}",
"DB_PASSWORD": "${DB_PASSWORD}"
}
}
}User Environment Variables
# User sets these in their shell
export DATABASE_URL="postgresql://localhost/mydb"
export DB_USER="myuser"
export DB_PASSWORD="mypassword"Documentation Template
## Database Configuration
Set these environment variables:
\`\`\`bash
export DATABASE_URL="postgresql://host:port/database"
export DB_USER="username"
export DB_PASSWORD="password"
\`\`\`
Or create a `.env` file (add to `.gitignore`):
\`\`\`
DATABASE_URL=postgresql://localhost:5432/mydb
DB_USER=myuser
DB_PASSWORD=mypassword
\`\`\`
Load with: \`source .env\` or \`export $(cat .env | xargs)\`
\`\`\`Dynamic Headers
Headers Helper Script
For tokens that change or expire, use a helper script:
{
"api": {
"type": "sse",
"url": "https://api.example.com",
"headersHelper": "${CLAUDE_PLUGIN_ROOT}/scripts/get-headers.sh"
}
}Script (get-headers.sh):
#!/bin/bash
# Generate dynamic authentication headers
# Fetch fresh token
TOKEN=$(get-fresh-token-from-somewhere)
# Output JSON headers
cat <<EOF
{
"Authorization": "Bearer $TOKEN",
"X-Timestamp": "$(date -Iseconds)"
}
EOFUse Cases for Dynamic Headers
Short-lived tokens that need refresh
Tokens with HMAC signatures
Time-based authentication
Dynamic tenant/workspace selection
Security Best Practices
DO
✅ Use environment variables:
{
"headers": {
"Authorization": "Bearer ${API_TOKEN}"
}
}✅ Document required variables in README
✅ Use HTTPS/WSS always
✅ Implement token rotation
✅ Store tokens securely (env vars, not files)
✅ Let OAuth handle authentication when available
DON'T
❌ Hardcode tokens:
{
"headers": {
"Authorization": "Bearer sk-abc123..." // NEVER!
}
}❌ Commit tokens to git
❌ Share tokens in documentation
❌ Use HTTP instead of HTTPS
❌ Store tokens in plugin files
❌ Log tokens or sensitive headers
Multi-Tenancy Patterns
Workspace/Tenant Selection
Via environment variable:
{
"api": {
"type": "http",
"url": "https://api.example.com/mcp",
"headers": {
"Authorization": "Bearer ${API_TOKEN}",
"X-Workspace-ID": "${WORKSPACE_ID}"
}
}
}Via URL:
{
"api": {
"type": "http",
"url": "https://${TENANT_ID}.api.example.com/mcp"
}
}Per-User Configuration
Users set their own workspace:
export WORKSPACE_ID="my-workspace-123"
export TENANT_ID="my-company"Authentication Troubleshooting
Common Issues
401 Unauthorized:
Check token is set correctly
Verify token hasn't expired
Check token has required permissions
Ensure header format is correct
403 Forbidden:
Token valid but lacks permissions
Check scope/permissions
Verify workspace/tenant ID
May need admin approval
Token not found:
# Check environment variable is set
echo $API_TOKEN
# If empty, set it
export API_TOKEN="your-token"Token in wrong format:
// Correct
"Authorization": "Bearer sk-abc123"
// Wrong
"Authorization": "sk-abc123"Debugging Authentication
Enable debug mode:
claude --debugLook for:
Authentication header values (sanitized)
OAuth flow progress
Token refresh attempts
Authentication errors
Test authentication separately:
# Test HTTP endpoint
curl -H "Authorization: Bearer $API_TOKEN" \
https://api.example.com/mcp/health
# Should return 200 OKMigration Patterns
From Hardcoded to Environment Variables
Before:
{
"headers": {
"Authorization": "Bearer sk-hardcoded-token"
}
}After:
{
"headers": {
"Authorization": "Bearer ${API_TOKEN}"
}
}Migration steps:
Add environment variable to plugin README
Update configuration to use ${VAR}
Test with variable set
Remove hardcoded value
Commit changes
From Basic Auth to OAuth
Before:
{
"headers": {
"Authorization": "Basic ${BASE64_CREDENTIALS}"
}
}After:
{
"type": "sse",
"url": "https://mcp.example.com/sse"
}Benefits:
Better security
No credential management
Automatic token refresh
Scoped permissions
Advanced Authentication
Mutual TLS (mTLS)
Some enterprise services require client certificates.
Not directly supported in MCP configuration.
Workaround: Wrap in stdio server that handles mTLS:
{
"secure-api": {
"command": "${CLAUDE_PLUGIN_ROOT}/servers/mtls-wrapper",
"args": ["--cert", "${CLIENT_CERT}", "--key", "${CLIENT_KEY}"],
"env": {
"API_URL": "https://secure.example.com"
}
}
}JWT Tokens
Generate JWT tokens dynamically with headers helper:
#!/bin/bash
# generate-jwt.sh
# Generate JWT (using library or API call)
JWT=$(generate-jwt-token)
echo "{\"Authorization\": \"Bearer $JWT\"}"{
"headersHelper": "${CLAUDE_PLUGIN_ROOT}/scripts/generate-jwt.sh"
}HMAC Signatures
For APIs requiring request signing:
#!/bin/bash
# generate-hmac.sh
TIMESTAMP=$(date -Iseconds)
SIGNATURE=$(echo -n "$TIMESTAMP" | openssl dgst -sha256 -hmac "$SECRET_KEY" | cut -d' ' -f2)
cat <<EOF
{
"X-Timestamp": "$TIMESTAMP",
"X-Signature": "$SIGNATURE",
"X-API-Key": "$API_KEY"
}
EOFBest Practices Summary
For Plugin Developers
Prefer OAuth when service supports it
Use environment variables for tokens
Document all required variables in README
Provide setup instructions with examples
Never commit credentials
Use HTTPS/WSS only
Test authentication thoroughly
For Plugin Users
Set environment variables before using plugin
Keep tokens secure and private
Rotate tokens regularly
Use different tokens for dev/prod
Don't commit .env files to git
Review OAuth scopes before authorizing
Conclusion
Choose the authentication method that matches your MCP server's requirements:
OAuth for cloud services (easiest for users)
Bearer tokens for API services
Environment variables for stdio servers
Dynamic headers for complex auth flows
Always prioritize security and provide clear setup documentation for users.
Requirements and compatibility
Written for: Claude Code, Claude apps
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an MCP server, Needs an API key, Needs Python, Needs Node.js
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Anthropic
- Publisher
- Anthropic (Official)
- Source
- anthropics/claude-plugins-official · plugins/plugin-dev/skills/mcp-integration · commit 0412be7
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from plugins/plugin-dev/LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Anthropic or Anthropic.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download mcp-integration.zip