Skip to main content
Glama
michaelkrasa

Alpha ESS MCP Server

by michaelkrasa

get_ess_list

Retrieve registered Alpha ESS solar and battery systems with structured metadata and automatic selection recommendations for monitoring and configuration.

Instructions

Get list of registered Alpha ESS systems with auto-selection logic.
Returns enhanced system information with structured metadata.

Returns:
    dict: Enhanced response with system list and auto-selection recommendations

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • main.py:405-449 (handler)
    MCP tool handler for get_ess_list. Fetches ESS systems list via helper, structures with models, and returns enhanced response. Includes @mcp.tool() registration.
    @mcp.tool()
    async def get_ess_list() -> dict[str, Any]:
        """
        Get list of registered Alpha ESS systems with auto-selection logic.
        Returns enhanced system information with structured metadata.
        
        Returns:
            dict: Enhanced response with system list and auto-selection recommendations
        """
        serial_info = await get_default_serial()
    
        if serial_info['success']:
            systems = [SystemInfo(
                serial=s.get('sysSn'),
                name=s.get('sysName', 'Unknown'),
                status=s.get('sysStatus', 'Unknown')
            ) for s in serial_info['systems']]
    
            structured = SystemList(
                recommended_serial=serial_info.get('serial'),
                systems=systems,
                requires_selection=serial_info.get('serial') is None
            )
    
            return create_enhanced_response(
                success=True,
                message=serial_info['message'],
                raw_data=serial_info['systems'],
                data_type="system_list",
                metadata={
                    "total_systems": len(serial_info['systems']),
                    "auto_selected_serial": serial_info.get('serial'),
                    "selection_strategy": "single_system_auto" if serial_info.get('serial') else "multiple_systems_manual"
                },
                structured_data=structured
            )
        else:
            return create_enhanced_response(
                success=False,
                message=serial_info['message'],
                raw_data=None,
                data_type="system_list",
                metadata={"error_type": "no_systems_found"}
            )
  • Core helper function that authenticates with AlphaESS API, calls getESSList(), and implements auto-selection logic for single/multiple systems.
    async def get_default_serial() -> dict[str, Any]:
        """
        Get the default serial number to use. If only one system is registered,
        returns that serial. If multiple systems, returns list for user to choose.
        
        Returns:
            dict: Result with serial info
        """
        client = None
        try:
            app_id, app_secret = get_alpha_credentials()
            client = alphaess(app_id, app_secret)
    
            # Get ESS list
            ess_list = await client.getESSList()
    
            if not ess_list or len(ess_list) == 0:
                return {
                    "success": False,
                    "message": "No Alpha ESS systems found in your account",
                    "serial": None,
                    "systems": []
                }
    
            if len(ess_list) == 1:
                # Auto-select the only system
                system = ess_list[0]
                serial = system.get('sysSn') if isinstance(system, dict) else getattr(system, 'sysSn', None)
                return {
                    "success": True,
                    "message": f"Auto-selected single system: {serial}",
                    "serial": serial,
                    "systems": ess_list
                }
            else:
                # Multiple systems - return list for user choice
                systems_info = []
                for system in ess_list:
                    if isinstance(system, dict):
                        systems_info.append({
                            "serial": system.get('sysSn'),
                            "name": system.get('sysName', 'Unknown'),
                            "status": system.get('sysStatus', 'Unknown')
                        })
                    else:
                        systems_info.append({
                            "serial": getattr(system, 'sysSn', 'Unknown'),
                            "name": getattr(system, 'sysName', 'Unknown'),
                            "status": getattr(system, 'sysStatus', 'Unknown')
                        })
    
                return {
                    "success": True,
                    "message": f"Found {len(ess_list)} systems. Please specify which serial to use.",
                    "serial": None,
                    "systems": systems_info
                }
    
        except Exception as e:
            return {
                "success": False,
                "message": f"Error getting system list: {str(e)}",
                "serial": None,
                "systems": []
            }
        finally:
            if client:
                await client.close()
  • Dataclasses defining structured output types for ESS systems list: SystemInfo (individual system) and SystemList (list with recommendations). Used in get_ess_list response.
    @dataclass
    class SystemInfo:
        serial: str
        name: str
        status: str
    
    
    @dataclass
    class SystemList:
        recommended_serial: Optional[str]
        systems: List[SystemInfo]
        requires_selection: bool
  • main.py:24-52 (helper)
    Utility function to create standardized enhanced responses used by get_ess_list and other tools.
    def create_enhanced_response(
            success: bool,
            message: str,
            raw_data: Any,
            data_type: DataType,
            serial_used: Optional[str] = None,
            metadata: Optional[Dict[str, Any]] = None,
            structured_data: Optional[Any] = None
    ) -> Dict[str, Any]:
        """Create a standardized response with enhanced structure"""
        response = {
            "success": success,
            "message": message,
            "data_type": data_type,
            "metadata": {
                "timestamp": datetime.now().isoformat(),
                **({"serial_used": serial_used} if serial_used else {}),
                **(metadata or {})
            },
            "data": raw_data
        }
    
        if structured_data is not None:
            if is_dataclass(structured_data):
                response["structured"] = asdict(structured_data)
            else:
                response["structured"] = structured_data
    
        return response
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'auto-selection logic' and 'enhanced system information', which adds some context about what the tool does beyond basic listing. However, it fails to disclose critical behavioral traits such as whether this requires authentication (unlike 'authenticate_alphaess'), rate limits, error handling, or what 'auto-selection' entails operationally. The description is too vague about the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with three sentences that each add value: stating the action, detailing the return content, and specifying the return type. It is front-loaded with the core purpose. There is minimal waste, though the 'Returns:' label is slightly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 0 parameters, an output schema exists, and no annotations are provided, the description is moderately complete. It explains the tool's purpose and return value, which the output schema will detail further. However, for a tool with 'auto-selection logic' and in a context with multiple sibling tools, more guidance on usage and behavior would improve completeness, especially since annotations are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. The baseline for 0 parameters is 4, as no compensation is needed, and the description doesn't introduce confusion about parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('list of registered Alpha ESS systems'), making the purpose understandable. It distinguishes from siblings by mentioning 'auto-selection logic' and 'enhanced system information', which differentiates it from simpler data retrieval tools like 'get_alpha_ess_data'. However, it doesn't explicitly contrast with all siblings, preventing a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_alpha_ess_data' or 'get_last_power_data'. It mentions 'auto-selection logic' but doesn't explain when this is beneficial or what scenarios warrant its use. No exclusions or prerequisites are stated, leaving the agent with minimal usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/michaelkrasa/alpha-ess-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server