Add support for Model Context Protocol (MCP) integration

[nickels]

Is your feature request related to a problem? Please describe.

Currently, EVCC’s rich energy management data and control capabilities are only accessible through its REST API, MQTT API, and web interface. With the growing adoption of AI assistants and automation tools that support the Model Context Protocol (MCP), there’s no standardized way for AI systems to integrate with EVCC for intelligent energy management workflows.

Users who want to build AI-powered energy management assistants, voice-controlled charging systems, or intelligent automation workflows must implement custom integrations rather than leveraging the emerging MCP standard.

Describe the solution you’d like

Implementation of a Model Context Protocol (MCP) server that exposes EVCC’s capabilities to MCP-compatible AI assistants and tools. This would enable:

Resources (Data Access):

• Current charging status and session data
• Energy generation and consumption metrics
• Vehicle state information (SoC, range, etc.)
• Battery and inverter status
• Historical charging session data
• Site configuration and loadpoint status

Tools (Control Functions):

• Start/stop charging sessions
• Set charging modes (PV-only, min+PV, fast, off)
• Configure charge limits and target SoC
• Adjust charging current limits
• Enable/disable loadpoints
• Update vehicle target times

Example MCP Use Cases:

• “Hey Claude, start charging my car with solar power only”
• “What was my charging efficiency yesterday?”
• “Set up optimal charging for my trip tomorrow morning”
• AI-driven energy optimization based on weather forecasts and electricity prices
• Integration with smart home assistants for comprehensive energy management

Describe alternatives you’ve considered

• Custom REST API integrations: Requires manual implementation for each AI tool
• MQTT bridges: Not standardized and requires custom parsing logic
• Home Assistant integration: Limited to HA ecosystem and doesn’t provide the rich context MCP offers
• Webhook solutions: One-way communication and complex setup

Technical Implementation Details

The MCP server could be implemented as:

1. Embedded MCP server: Integrated directly into EVCC core (similar to existing web server)
2. Standalone MCP bridge: Separate service that communicates with EVCC via existing APIs
3. Plugin architecture: MCP support as an optional plugin/addon

Proposed Architecture:

AI Assistant/MCP Client <-> MCP Protocol <-> EVCC MCP Server <-> EVCC Core

Protocol Support:

• HTTP + Server-Sent Events (SSE) transport
• JSON-RPC message format
• OAuth 2.0 authentication (optional)
• Real-time data streaming for monitoring use cases

Additional context

Industry Adoption:
Model Context Protocol is rapidly becoming the standard for AI-system integrations, with support from:

• Anthropic (Claude Desktop)
• Microsoft (Copilot Studio)
• Major development tools (VS Code, Cursor, Replit)
• Enterprise platforms (Atlassian, Pomerium)

Benefits for EVCC Community:

• Enhanced accessibility for non-technical users through natural language interfaces
• Rich ecosystem of AI-powered energy management tools
• Future-proof integration standard
• Potential for community-contributed MCP workflows and automations

Security Considerations:

• Authentication and authorization controls
• Rate limiting for API access
• Secure credential management
• Audit logging for MCP tool invocations

This feature would position EVCC as a leader in AI-enabled energy management and significantly expand its integration possibilities with the growing ecosystem of MCP-compatible tools and platforms.

Implementation Priority

This could be considered a low-to-medium priority enhancement that would:

• Expand EVCC’s integration ecosystem
• Future-proof the platform for AI-driven energy management
• Attract developers building AI-powered smart home solutions
• Align with industry trends toward standardized AI integrations

Would the EVCC team be open to exploring this integration? I’d be happy to contribute to the design discussion or implementation efforts.

[andig]

Refs https://github.com/mark3labs/mcp-go

[andig]

@nickels great request, much appreciated! I'd absolutely like to do this for the energy optimization use case. The technology is super interesting and it would be great to see if it could enhance evcc's capabilities in that area.

I'm personally less interested in "voice" integration, using MCP as proxy for simple commands. At least in the past there was close to zero demand for Alexa etc.

Going for optimization use cases it would be great if- instead of building "anything possible" we could experiment and take it feature by feature. That said: is there a "minimum" one would need to enable something like your example above? Wat is the minimum to get results?

“Set up optimal charging for my trip tomorrow morning”

Please note that /api/state already exposes almost all state information evcc has. Would that already be usable by an API-consuming agent or do we need to translate that into individual MCP use cases?

[nickels]

@andig Great question about API consumption vs. MCP translation. Looking at the autonomous intelligence use case, I think we need both layers for different reasons, and this actually clarifies where MCP provides genuine value.

The Autonomous Intelligence Loop

The compelling use case isn't just "Need 80% by 7 AM" - it's the autonomous context synthesis that generates that request. Calendar meeting in Frankfurt → route analysis → EVCC's learned consumption patterns → optimized MCP request back to EVCC planner.

Intelligence synthesis pipeline (external to EVCC scope):

• MS 365 MCP Server extracts calendar events
• Local/cloud LLM parses meeting locations and trip requirements
• Calendar AutoAuth MCP handles route analysis

EVCC's role in the ecosystem:

• EVCC MCP Server provides vehicle consumption patterns from existing vehicle abstraction layer
• Intelligence synthesis generates structured request: "Need 80% by 7 AM" with enhanced context and connects to EVCC MCP Server to convey the message

API Consumption vs. MCP Translation

The existing /api/state provides excellent raw data, but external agents face significant barriers for complex optimization:

• Domain complexity: Understanding loadpoint priorities, phase switching, thermal management
• Temporal reasoning: Correlating pricing windows with charging curves and departure constraints
• Vehicle specifics: Interpreting consumption patterns, efficiency variations, battery conditioning needs

An API-consuming agent would need deep EVCC expertise to synthesize this correctly.

MCP enables domain-specific abstractions that embed EVCC's operational intelligence:

Resources:

• evcc://optimization/charging-windows - pre-processed opportunity analysis
• evcc://vehicle/consumption-patterns - learned efficiency characteristics
• evcc://context/trip-requirements - constraint-aware planning inputs

Tools:

• calculate_charging_strategy - input constraints, output optimized schedule
• analyze_scenario - what-if analysis for different departure times

Architectural Elegance

This creates a closed-loop system where EVCC serves dual roles: authoritative source of vehicle energy intelligence and execution engine for autonomously optimized decisions. The existing planner handles optimization perfectly - MCP enables external intelligence systems to leverage EVCC's operational expertise without becoming domain experts themselves.

mark3labs/mcp-go Integration

Clean integration path with existing architecture. MCP becomes optional intelligence interface alongside HTTP API - start with enhanced /api/state exposure via MCP resources, then add domain-specific tools as we validate which abstractions genuinely improve decision quality over raw API consumption.

Validation Framework

Key question: does autonomous context synthesis consistently generate better optimization decisions than manual planning? For simple scenarios, /api/state + smart agent might suffice. But for the autonomous intelligence loop, MCP translation becomes essential to enable ecosystem innovation without forcing external agents to understand EVCC's internal complexity.

This enables EVCC to be used as an anticipatory energy intelligence platform while preserving its core strength as a robust charge controller. The external intelligence synthesis demonstrates one compelling use case for how EVCC's MCP interface could enable broader ecosystem innovation.

Worth prototyping both approaches to validate where MCP abstraction adds genuine value versus API sufficiency?

[andig]

I have to admit that you're far ahead and I have trouble keeping up. I've tried to draft a very simple MCP server. I'd appreciate if we could tune it to do anything useful at all ;). Added a few question. Answers and fixes to the simplistic code welcome.

[daniel309]

Another solution could be to simply "convert" the EVCC REST API through MCP forge?
--> https://github.com/IBM/mcp-context-forge

"... Converts REST API endpoints to MCP, ..."

[andig]

I can‘t connect Claude to MCP: TBXark/mcp-proxy#27

[andig]

@nickels are you meanwhile able to connect the MCP to Claude (or any other agent)? Without that we might as well close here...

[andig]

Closing here- we can continue discussion in PR. There are so many open "how to effectively..." questions that it's unlikely we'll have any short-term success. Feel free to join the slack #ai channel.