Files
n8n-mcp/HTTP_REMOTE_SUMMARY.md
czlonkowski 23a21071bc docs: add comprehensive HTTP remote deployment planning documentation
- HTTP_REMOTE_DEPLOYMENT_PLAN.md: High-level architecture and implementation plan
- HTTP_IMPLEMENTATION_GUIDE.md: Detailed technical implementation with code examples
- HTTP_IMPLEMENTATION_ROADMAP.md: Day-by-day implementation checklist and milestones
- HTTP_REMOTE_SUMMARY.md: Executive summary with key findings and recommendations
- Updated README.md with references to future HTTP deployment plans

Key findings:
- Claude Desktop currently only supports stdio transport (local execution)
- mcp-remote adapter enables remote server connectivity as a bridge solution
- Implementation requires adding StreamableHTTPServerTransport support
- Dual-mode operation will maintain backward compatibility

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-06-13 11:22:48 +02:00

6.8 KiB

HTTP Remote Deployment - Executive Summary

Current Situation

The n8n-MCP server currently only works locally on the same machine as Claude Desktop. This limits its usefulness and prevents centralized deployment, updates, and management.

Key Finding: Claude Desktop Limitation

Critical Discovery: Claude Desktop does NOT currently support remote MCP servers natively. It only supports the stdio (standard input/output) transport protocol, which requires local execution.

The Solution: mcp-remote Bridge

The MCP community has developed mcp-remote, an adapter that bridges the gap:

  • Acts as a local stdio server that Claude Desktop can communicate with
  • Forwards requests to remote HTTP MCP servers
  • Handles authentication and session management
  • Provides transparent proxy functionality

Implementation Overview

1. Server-Side Changes

We need to add HTTP transport support to n8n-MCP:

// New capabilities to add:
- HTTP endpoint (/mcp) that accepts JSON-RPC requests
- Session management for stateful connections  
- Bearer token authentication
- HTTPS/TLS encryption
- Health check endpoints

2. Dual-Mode Operation

The server will support both modes:

  • stdio mode: Current local operation (no changes for existing users)
  • http mode: New remote operation for internet deployment

3. Client Configuration

Users will configure Claude Desktop like this:

{
  "mcpServers": {
    "n8n-remote": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote@latest",
        "connect",
        "https://your-mcp-server.com/mcp"
      ],
      "env": {
        "MCP_AUTH_TOKEN": "your-secure-token"
      }
    }
  }
}

Technical Architecture

Components

  1. Express.js HTTP Server

    • Handles incoming HTTP requests
    • Manages authentication
    • Provides CORS support
  2. StreamableHTTPServerTransport

    • MCP SDK's HTTP transport implementation
    • Handles JSON-RPC protocol
    • Supports Server-Sent Events for bidirectional communication
  3. Session Manager

    • Creates unique sessions per client
    • Maintains state between requests
    • Handles cleanup of inactive sessions
  4. Database Adapter

    • Our existing adapter works perfectly
    • Handles concurrent access
    • No changes needed

Security Model

  1. Authentication: Bearer token in Authorization header
  2. Encryption: HTTPS/TLS required for production
  3. Rate Limiting: Prevent abuse and DDoS
  4. Input Validation: Sanitize all inputs
  5. CORS: Restrict allowed origins

Deployment Options

Option 1: VPS/Cloud VM

  • Full control over environment
  • Can handle many concurrent users
  • Requires server management

Option 2: Docker Container

  • Easy deployment and updates
  • Consistent environment
  • Good for scaling

Option 3: Managed Platforms

  • Cloudflare Workers (with limitations)
  • AWS Lambda (stateless challenges)
  • Heroku/Railway (simple deployment)

Implementation Phases

Phase 1: Core HTTP Server (Week 1)

  • Implement Express server with MCP endpoint
  • Add StreamableHTTPServerTransport
  • Basic authentication
  • Session management

Phase 2: Integration (Week 2)

  • Modify existing server for dual-mode
  • Add configuration system
  • Update entry points
  • Maintain backward compatibility

Phase 3: Deployment (Week 3)

  • Create Docker container
  • Write deployment scripts
  • Set up nginx/SSL
  • Document setup process

Phase 4: Testing & Launch (Week 4)

  • Security testing
  • Performance testing
  • Documentation
  • Community release

Benefits

  1. Centralized Management

    • Single server for multiple users
    • Easy updates and maintenance
    • Consistent experience
  2. No Local Installation

    • Users don't need Node.js
    • No dependency management
    • Works on any OS
  3. Enterprise Ready

    • Authentication and access control
    • Monitoring and logging
    • Scalable architecture
  4. Cost Effective

    • One server serves many users
    • Efficient resource usage
    • Pay for what you use

Challenges & Solutions

Challenge Solution
Claude Desktop doesn't support HTTP Use mcp-remote adapter
Session state management Implement session manager with timeout
Security concerns Strong auth, HTTPS, rate limiting
Database concurrency Our adapter already handles this
Performance at scale Caching, CDN, horizontal scaling

Cost Estimate

Small Deployment (< 50 users)

  • VPS: $10-20/month
  • Domain: $10/year
  • SSL: Free (Let's Encrypt)
  • Total: ~$15/month

Medium Deployment (50-500 users)

  • Better VPS: $40-80/month
  • CDN: $20/month
  • Monitoring: $10/month
  • Total: ~$70/month

Large Deployment (500+ users)

  • Load balanced setup: $200+/month
  • Redis for sessions: $30/month
  • Advanced monitoring: $50/month
  • Total: ~$280/month

Success Metrics

  1. Technical Success

    • All MCP tools work remotely
    • Response time < 200ms
    • 99.9% uptime
  2. User Success

    • Easy setup (< 5 minutes)
    • Clear documentation
    • Positive feedback
  3. Operational Success

    • Low maintenance overhead
    • Automated monitoring
    • Smooth updates
  1. Immediate Actions

    • Review and approve the implementation plan
    • Set up development environment
    • Begin Phase 1 implementation
  2. Short Term (1-2 weeks)

    • Complete HTTP server implementation
    • Test with mcp-remote
    • Deploy beta version
  3. Medium Term (3-4 weeks)

    • Production deployment
    • Documentation and guides
    • Community announcement
  4. Long Term (2-3 months)

    • Gather feedback
    • Implement enhancements
    • Consider enterprise features

Conclusion

Adding HTTP remote deployment to n8n-MCP is technically feasible and highly beneficial. While Claude Desktop's current limitations require using the mcp-remote adapter, this is a proven solution already in use by other MCP servers.

The implementation is straightforward, building on our existing robust architecture. The database adapter system we recently implemented will work perfectly in a multi-user environment.

This enhancement will transform n8n-MCP from a local tool to a cloud-ready service, greatly expanding its reach and usefulness to the Claude Desktop community.

Key Decision Points

  1. Should we proceed with HTTP implementation?

    • Recommendation: Yes, the benefits far outweigh the complexity
  2. Which deployment option should we prioritize?

    • Recommendation: Start with VPS + Docker for flexibility
  3. How should we handle authentication?

    • Recommendation: Start with Bearer tokens, consider OAuth2 later
  4. When should we launch?

    • Recommendation: Beta in 2 weeks, production in 4 weeks

The path forward is clear, and the technical approach is sound. With careful implementation and testing, n8n-MCP can become a premier remote MCP service for the Claude Desktop ecosystem.