Skip to main content
Glama
adrighem

Domoticz MCP Server

by adrighem

analyze_energy_usage

Summarize today's energy consumption by analyzing all energy-reporting devices in your Domoticz system.

Instructions

Analyze all energy-reporting devices and summarize their 'Today' usage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The actual tool handler function implementation: fetches all devices, filters for those with 'Usage' or 'CounterToday' fields, and returns a JSON summary of energy usage per device.
    @mcp.tool()
    async def analyze_energy_usage() -> str:
        """Analyze all energy-reporting devices and summarize their 'Today' usage."""
        async with create_client() as client:
            devices = await _get_cached_data(client, _device_cache, f"{DOMOTICZ_API_URL}?type=command¶m=getdevices&filter=all&used=true")
            results = []
            
            # Look for devices with 'Usage' or 'Counter' related fields
            for dev in devices:
                usage = dev.get("Usage")
                counter_today = dev.get("CounterToday")
                
                if usage is not None or counter_today is not None:
                    results.append({
                        "idx": dev.get("idx"),
                        "Name": dev.get("Name"),
                        "CurrentUsage": usage,
                        "TodayTotal": counter_today,
                        "Type": dev.get("Type"),
                        "SubType": dev.get("SubType")
                    })
            
            return json.dumps({"status": "OK", "result": results})
  • The @mcp.tool() decorator registers 'analyze_energy_usage' as an MCP tool.
    @mcp.tool()
  • Helper function _resolve_device_idx and _get_cached_data used by the handler to fetch and cache device data.
    async def _resolve_device_idx(client: "httpx.AsyncClient", idx: Optional[int] = None, name: Optional[str] = None) -> Optional[int]:
        """Resolve a device to its idx."""
        return await _resolve_idx(client, idx, name, _device_cache, f"{DOMOTICZ_API_URL}?type=command¶m=getdevices&filter=all&used=true")
  • Helper function _simplify_device used to reduce device dictionaries (not directly used by analyze_energy_usage but part of the device processing patterns).
    def _simplify_device(dev: Dict[str, Any]) -> Dict[str, Any]:
        """Reduce device dictionary to essential fields to save context space."""
        keys_to_keep = [
            "idx", "Name", "Type", "SubType", "Data", "Status", 
            "BatteryLevel", "Favorite", "HardwareName", "LastUpdate", 
            "TypeImg", "Usage", "CounterToday", "Temp", "Humidity"
        ]
        return {k: dev[k] for k in keys_to_keep if k in dev}
  • Test for the analyze_energy_usage tool, verifying it filters devices without energy data and returns only those with Usage/CounterToday fields.
    @respx.mock
    async def test_analyze_energy_usage():
Behavior2/5

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

No annotations provided. Description only says 'analyze' and 'summarize', not disclosing whether it's read-only, side effects, or what summary includes. Insufficient behavioral context.

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?

One efficient sentence with no waste, but could be slightly more informative for a zero-param tool.

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?

Adequate for a simple, parameterless tool with output schema; however, lacks detail on what 'summarize' entails.

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?

No parameters exist; baseline 4 per instructions. Description adds no needed parameter info beyond schema.

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

Purpose5/5

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

Clearly states verb 'analyze', resource 'all energy-reporting devices', and scope 'summarize Today usage'. No sibling tool focuses on energy analysis, making it distinct.

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

Usage Guidelines3/5

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

Implied usage for energy analysis, but no explicit when-to-use/when-not-to-use or alternatives provided.

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/adrighem/domoticz-mcp'

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