Skip to main content
Glama
huber

Fronius MCP Server

by huber
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Fronius MCP Server

CI/CD Pipeline Docker Hub GitHub release License Node.js Version TypeScript

A Model Context Protocol (MCP) server for the Fronius Solar API. This server enables access to Fronius inverter data through the MCP protocol for direct use in Claude Desktop or any other MCP Host Application.

Features

  • ✅ Full TypeScript implementation with strong typing

  • ✅ Comprehensive Fronius Solar API v1 coverage - all major endpoints

  • ✅ Configurable settings via environment variables

  • ✅ Both Resources and Tools for maximum flexibility

  • ✅ Connection testing on startup and via tools

  • ✅ Claude Desktop integration with network permissions guide

Related MCP server: Tigo Energy MCP Server

Supported Fronius API Endpoints

System & Status

  • GetAPIVersion.cgi - API Version

  • GetLoggerInfo.cgi - System Status

  • GetLoggerLEDInfo.cgi - LED Status

  • GetActiveDeviceInfo.cgi - Active Devices

Inverter

  • GetInverterInfo.cgi - Static inverter information

  • GetInverterRealtimeData.cgi - Real-time data (various DataCollections)

Smart Meter & Power Flow

  • GetMeterRealtimeData.cgi - Smart meter real-time data

  • GetPowerFlowRealtimeData.fcgi - Energy flow visualization

Battery Storage

  • GetStorageRealtimeData.cgi - Battery storage system data (state of charge, power, temperature)

Smart Home Integration

  • GetOhmPilotRealtimeData.cgi - OhmPilot smart heating element controller data

Extended Features

  • GetArchiveData.cgi - Archive data with flexible time ranges

  • GetSensorRealtimeData.cgi - Environmental sensors (temperature, irradiance)

  • GetStringRealtimeData.cgi - DC string data (voltage, current per string)

Requirements

  • Node.js 20+ (tested with Node.js 24)

  • npm or yarn

Installation

# Clone repository
git clone https://github.com/huber/fronius-mcp-server.git
cd fronius-mcp-server

# Install dependencies
npm install

# Build TypeScript
npm run build

Configuration

Environment Variables

Copy .env.example to .env and adjust values:

cp .env.example .env

Available configuration options:

  • FRONIUS_HOST - Hostname or IP of Fronius device (default: fronius-inverter)

  • FRONIUS_PORT - Port (default: 80)

  • FRONIUS_PROTOCOL - Protocol: http or https (default: http)

  • FRONIUS_TIMEOUT - Request timeout in ms (default: 10000)

  • FRONIUS_DEVICE_ID - Default device ID (default: 1)

  • FRONIUS_RETRIES - Number of retry attempts (default: 3)

  • FRONIUS_RETRY_DELAY - Delay between retries in ms (default: 1000)

  • LOG_LEVEL - Log level: error, warn, info, debug (default: info)

Example Configurations

Local Fronius device with hostname:

FRONIUS_HOST=fronius-inverter.local

With IP address:

FRONIUS_HOST=192.168.1.100

HTTPS (newer models):

FRONIUS_HOST=192.168.1.100
FRONIUS_PROTOCOL=https
FRONIUS_PORT=443

Installation Options

Option 1: NPM Package (Easiest)

The simplest way to install and use the Fronius MCP Server is via npm:

Global Installation

1. Install globally:

npm install -g fronius-mcp-server

2. Run directly:

# Basic usage
fronius-mcp-server --host fronius-inverter.local

# Advanced usage with HTTPS
fronius-mcp-server --host 192.168.1.100 --protocol https --port 443

# Test connection
fronius-mcp-server --test-connection --host fronius-inverter.local

Claude Desktop Configuration

Edit your Claude Desktop configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Basic Configuration:

{
  "mcpServers": {
    "fronius-solar": {
      "command": "fronius-mcp-server",
      "args": ["--host", "fronius-inverter.local"]
    }
  }
}

Advanced Configuration:

{
  "mcpServers": {
    "fronius-solar": {
      "command": "fronius-mcp-server",
      "args": [
        "--host", "192.168.1.100",
        "--protocol", "https",
        "--port", "443",
        "--timeout", "15000"
      ]
    }
  }
}

CLI Options

fronius-mcp-server --help

Options:
  -h, --host <host>           Fronius inverter hostname or IP address
  -p, --port <port>           Fronius inverter port (default: 80)
  --protocol <protocol>       Protocol http|https (default: http)
  -t, --timeout <timeout>     Request timeout in ms (default: 10000)
  -d, --device-id <deviceId>  Default device ID (default: 1)
  -r, --retries <retries>     Number of retry attempts (default: 3)
  --retry-delay <delay>       Delay between retries in ms (default: 1000)
  -l, --log-level <level>     Log level (default: info)
  --test-connection          Test connection and exit
  --stdio                    Use stdio transport (default for MCP)
  --version                  Show version information

Advantages of NPM Installation

  • ✅ Zero setup - No Docker or Node.js project setup required

  • ✅ Global availability - Use fronius-mcp-server from anywhere

  • ✅ Easy updates - npm update -g fronius-mcp-server

  • ✅ Built-in CLI - Rich command-line interface with help

  • ✅ Cross-platform - Works on Windows, macOS, Linux

Option 2: Pre-built Docker Image

The easiest way to run the Fronius MCP Server is using the pre-built Docker image from Docker Hub:

Setup Steps

1. Pull the Pre-built Image

# No build required - use the pre-built image
docker pull dirkhuber/fronius-mcp-server:latest

Claude Desktop Configuration

Basic Configuration (Hostname):

{
  "mcpServers": {
    "fronius-solar": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "FRONIUS_HOST=fronius-inverter.local",
        "dirkhuber/fronius-mcp-server:latest"
      ]
    }
  }
}

Advanced Configuration (IP with HTTPS):

{
  "mcpServers": {
    "fronius-solar": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "FRONIUS_HOST=192.168.1.100",
        "-e", "FRONIUS_PROTOCOL=https",
        "-e", "FRONIUS_PORT=443",
        "-e", "FRONIUS_TIMEOUT=15000",
        "dirkhuber/fronius-mcp-server:latest"
      ]
    }
  }
}

That's it! No need to clone the repository or build anything. The pre-built Docker image contains everything needed.

Advantages of Pre-built Image

  • ✅ Zero setup - No cloning, building, or Node.js required

  • ✅ Always up-to-date - Latest stable version

  • ✅ Multi-platform - Supports both AMD64 and ARM64 architectures

  • ✅ Automatic updates - Pull new versions with docker pull dirkhuber/fronius-mcp-server:latest

Option 3: Build Docker Image Yourself

If you prefer to build the image yourself or want to modify the code:

Setup Steps

1. Build the Docker Image

# Clone and build the container image
git clone https://github.com/huber/fronius-mcp-server.git
cd fronius-mcp-server
npm run docker:build

2. Configure Claude Desktop

Edit your Claude Desktop configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Use the locally built image name fronius-mcp-server instead of the Docker Hub image:

Basic Configuration (Hostname):

{
  "mcpServers": {
    "fronius-solar": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "FRONIUS_HOST=fronius-inverter.local",
        "fronius-mcp-server"
      ]
    }
  }
}

Advanced Configuration (IP with HTTPS):

{
  "mcpServers": {
    "fronius-solar": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "FRONIUS_HOST=192.168.1.100",
        "-e", "FRONIUS_PROTOCOL=https",
        "-e", "FRONIUS_PORT=443",
        "-e", "FRONIUS_TIMEOUT=15000",
        "fronius-mcp-server"
      ]
    }
  }
}

How Docker Integration Works

  • Automatic Lifecycle: Claude Desktop starts a fresh container for each session

  • Environment Variables: Environment variables are passed directly as -e parameters in the args array

    • Each environment variable needs its own -e parameter

    • Format: "-e", "VARIABLE_NAME=value"

  • Auto-Cleanup: --rm flag removes container when session ends

  • No Manual Management: No need to manually start/stop containers

Equivalent Docker Command:

# For the basic configuration, Claude Desktop effectively runs:
docker run --rm -i \
  -e FRONIUS_HOST=fronius-inverter.local \
  dirkhuber/fronius-mcp-server:latest

# For the advanced configuration, it would run:
docker run --rm -i \
  -e FRONIUS_HOST=192.168.1.100 \
  -e FRONIUS_PROTOCOL=https \
  -e FRONIUS_PORT=443 \
  -e FRONIUS_TIMEOUT=15000 \
  dirkhuber/fronius-mcp-server:latest

Final Steps (for both options):

  1. Edit your Claude Desktop configuration file with one of the configurations above

  2. Completely quit Claude Desktop and restart it

  3. Begin a new conversation

  4. Test with: "How much power is my solar system producing?"

Alternative: Long-Running Container

If you prefer a long-running container approach:

Docker Compose Setup:

# Use docker-compose for easier management
cp .env.docker .env
# IMPORTANT: Edit .env and set FRONIUS_HOST to your device IP/hostname
# Example: FRONIUS_HOST=fronius-inverter.local or FRONIUS_HOST=192.168.1.100
docker-compose up -d

# Test the setup
./scripts/test-container.sh

Claude Desktop config for long-running container:

{
  "mcpServers": {
    "fronius-solar": {
      "command": "docker",
      "args": ["exec", "-i", "fronius-mcp-server", "node", "dist/server.js"],
      "env": {}
    }
  }
}

Note: For long-running containers, the FRONIUS_HOST is configured when starting the container (via docker-compose.yml or docker run), not in the Claude Desktop config. The docker exec command uses the environment from the running container.

Option 4: Local Development

For development or if you want to build from source:

Claude Desktop Setup

1. MCP Server Configuration

Edit the Claude Desktop configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\\Claude\\claude_desktop_config.json

{
  "mcpServers": {
    "fronius-solar": {
      "command": "node",
      "args": ["/absolute/path/to/fronius-mcp-server/dist/server.js"],
      "env": {
        "FRONIUS_HOST": "fronius-inverter.local"
      }
    }
  }
}

Important: Replace /absolute/path/to/fronius-mcp-server with your actual installation path!

Finding the correct paths:

# Find your installation path
pwd

# Find your node path (if Claude Desktop can't find node)
which node

# Example with full node path:
{
  "mcpServers": {
    "fronius-solar": {
      "command": "/usr/local/bin/node",
      "args": ["/Users/yourname/fronius-mcp-server/dist/server.js"],
      "env": {
        "FRONIUS_HOST": "fronius-inverter.local"
      }
    }
  }
}

2. 🔐 Network Permissions (macOS)

Claude Desktop requires access to the local network to communicate with the Fronius inverter.

How to enable permissions:

  1. System Settings → Privacy & Security → Network

  2. Find Claude in the app list

  3. ✅ Enable Network access for Claude Desktop

  4. Completely restart Claude Desktop

With macOS Firewall enabled, additionally:

  1. System Settings → Network → Firewall → Options

  2. Add Claude Desktop to exceptions list or create rule

3. Start and Test

After configuration:

  1. ⚠️ Completely quit Claude Desktop and restart

  2. Start new conversation

  3. Test with: "How much power is my solar system currently producing?"

Development & Testing

Development Mode

npm run dev

Production

npm run build
npm start

Testing & Debugging

# Full connection test
npm run test-connection

# Linting & Type Checking
npm run lint
npm run typecheck

MCP Resources

The server provides these resources:

  • fronius://api/version - API Version

  • fronius://system/status - System Status

  • fronius://system/led - LED Status

  • fronius://inverter/info - Inverter Information

  • fronius://inverter/realtime - Inverter Real-time Data

  • fronius://meter/realtime - Smart Meter Data

  • fronius://powerflow/realtime - Power Flow Data

  • fronius://sensors/realtime - Sensor Data

  • fronius://strings/realtime - String Data

  • fronius://storage/realtime - Battery Storage Data

  • fronius://ohmpilot/realtime - OhmPilot Data

  • fronius://devices/active - Active Devices

MCP Tools

Available tools for interactive queries:

  • get_api_version - Get API version

  • get_system_status - Get system status

  • get_logger_led_info - Get LED status

  • get_inverter_info - Get inverter information

  • get_inverter_realtime - Get inverter real-time data

  • get_meter_realtime - Get smart meter data

  • get_powerflow_realtime - Get power flow data

  • get_archive_data - Get historical data

  • get_sensor_realtime - Get sensor data

  • get_string_realtime - Get string data

  • get_storage_realtime - Get battery storage data

  • get_ohmpilot_realtime - Get OhmPilot data

  • get_active_devices - Get active devices

  • test_connection - Test connection

Tool Parameter Examples

Query specific inverter:

{
  "name": "get_inverter_realtime",
  "arguments": {
    "deviceId": 1,
    "dataCollection": "CommonInverterData"
  }
}

Get archive data:

{
  "name": "get_archive_data",
  "arguments": {
    "startDate": "2024-01-01",
    "endDate": "2024-01-31",
    "channel": "EnergyReal_WAC_Sum_Produced"
  }
}

Get battery storage data:

{
  "name": "get_storage_realtime",
  "arguments": {
    "deviceId": 0
  }
}

Get OhmPilot heating data:

{
  "name": "get_ohmpilot_realtime",
  "arguments": {
    "deviceId": 0
  }
}

Troubleshooting

Connection Issues

  1. Check hostname/IP:

    ping fronius-inverter.local
# or
ping 192.168.1.100

  2. Test API access:

    curl \"http://fronius-inverter.local/solar_api/GetAPIVersion.cgi\"

  3. Fronius Solar API enabled?

    • In Fronius web interface: System → Hardware → Datamanager

    • Solar API must be enabled

  4. Claude Desktop Network Permissions (macOS):

    • System Settings → Privacy & Security → Network

    • Allow Claude Desktop network access

  5. Firewall/Router:

    • Port 80/443 must be accessible

    • No firewall blocking between Claude Desktop and Fronius

Debugging

Enable debug logging:

LOG_LEVEL=debug npm run dev

Test API endpoints systematically:

FRONIUS_HOST=fronius-inverter.local npm run debug-fronius

Connection test:

FRONIUS_HOST=fronius-inverter.local npm run test-connection

Compatibility

Unsupported Features

  • Some older Fronius devices don't support all API endpoints

  • Archive data is not available on all models

Architecture

src/
├── types/           # TypeScript definitions
│   ├── fronius.ts   # Fronius API response types
│   └── config.ts    # Configuration types
├── services/        # Business logic
│   ├── fronius-api.ts  # Fronius API client with retry logic
│   └── config.ts    # Configuration service
├── handlers/        # MCP request handlers
│   ├── resources.ts # Resource-based data access
│   └── tools.ts     # Tool-based interactions
└── server.ts        # Main server with lifecycle management

Release Process

This project uses centralized version management - the version in package.json is the single source of truth for all components (MCP server config, User-Agent headers, etc.).

Creating a Release

1. Update Version

# Bump version in package.json (patch/minor/major)
npm version patch  # 1.0.0 -> 1.0.1
npm version minor  # 1.0.1 -> 1.1.0  
npm version major  # 1.1.0 -> 2.0.0

2. Build and Test

# Verify everything builds and tests pass
npm run build
npm run typecheck
npm run lint
npm run test-connection  # If Fronius device available

3. Create Git Tag and Release

# The npm version command automatically creates a git tag
# Push the tag to trigger GitHub Actions release workflow
git push origin main --tags

4. GitHub Actions will automatically:

  • ✅ Run full test suite on multiple Node.js versions

  • ✅ Build and test Docker image

  • ✅ Create GitHub release with changelog

  • ✅ Build and push multi-platform Docker images to Docker Hub

  • ✅ Create release archives (.tar.gz and .zip)

5. Docker Hub Update Once the GitHub release is published, users can update to the latest version:

docker pull dirkhuber/fronius-mcp-server:latest
# or specific version
docker pull dirkhuber/fronius-mcp-server:v1.0.1

Version Management

The version is centrally managed in package.json and automatically used by:

  • MCP Server Config (src/services/config.ts) - Server name and version

  • HTTP User-Agent (src/services/fronius-api.ts) - API client identification

  • Docker Tags (.github/workflows/ci.yml) - Container versioning

  • Release Assets (GitHub Actions) - Archive naming

Versioning Strategy

  • Patch (1.0.0 → 1.0.1): Bug fixes, small improvements

  • Minor (1.0.0 → 1.1.0): New features, API additions, non-breaking changes

  • Major (1.0.0 → 2.0.0): Breaking changes, API changes, major refactoring

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Commit your changes

  4. Push to the branch

  5. Create a Pull Request

License

MIT License - see LICENSE file for details.

Support

Available Tools

14 tools
get_active_devicesC

Get information about active devices in the system

ParametersJSON Schema
NameRequiredDescriptionDefault
deviceClassNoDevice class to querySystem

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits, but it only states that it retrieves information. It does not explain what 'active' means, whether the operation is safe/read-only, if authentication is needed, or what the response contains. Significant transparency gap.

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 a single, concise sentence that is direct and front-loaded. It is appropriately sized for a simple tool, though it sacrifices informative content for brevity.

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

Completeness2/5

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

Given no annotations, no output schema, and only one parameter, the description still fails to provide necessary context about what constitutes an active device, how the deviceClass filter works, and what kind of information is returned. It is incomplete for effective tool selection.

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

Parameters3/5

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

The schema covers 100% of the parameter (deviceClass) with a clear enum description, so the schema carries the load. The description adds no additional parameter semantics, but the baseline of 3 is appropriate.

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 uses the verb 'get' and specifies the resource 'active devices', which distinguishes it from sibling tools that target specific device types (e.g., inverter, meter). However, 'active devices' is somewhat ambiguous and does not leverage the deviceClass parameter to clarify scope.

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_inverter_info or get_meter_realtime. There is no mention of prerequisites, exclusions, or typical use cases.

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

get_api_versionA

Get Fronius Solar API version information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, but it doesn't explicitly state side effects, authentication, or return format. For a simple version information endpoint, this is minimally sufficient.

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

Conciseness5/5

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

Single concise sentence, front-loaded with the verb, no redundant words. Every word earns its place.

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

Completeness5/5

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

Given zero parameters and a straightforward informational purpose, the description is complete enough for an agent to select and invoke the tool correctly. No output schema is needed for such a simple version check.

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?

There are zero parameters, so the baseline for 0 params is 4. The description needs no additional parameter information since none exist.

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?

The description uses a specific verb 'Get' and a clear resource 'Fronius Solar API version information', distinguishing it from sibling tools that target specific device data (inverter, meter, etc.).

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?

No explicit when/when-not guidance or alternatives are mentioned, but the tool's purpose is self-evident for retrieving API version; usage is implied by the name and description.

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

get_archive_dataB

Get historical archive data for a specific time period

ParametersJSON Schema
NameRequiredDescriptionDefault
scopeNoData scopeSystem
channelNoData channel to retrieveEnergyReal_WAC_Sum_Produced
endDateYesEnd date in YYYY-MM-DD format
deviceIdNoDevice ID (required when scope is Device)
startDateYesStart date in YYYY-MM-DD format

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the burden of disclosing behavior. It implies a read-only operation via 'Get', but adds no context about potential side effects, rate limits, or output format. For a simple read operation this is minimally adequate, but it lacks any detailed behavioral transparency.

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

Conciseness5/5

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

The description is a single sentence with no redundancy, waste, or unnecessary detail. It directly states the tool's purpose in under 10 words.

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

Completeness2/5

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

Given no output schema, the description should explain what the caller receives, but it does not mention the return format or structure. The tool has multiple parameters and enums, yet the description offers no guidance on how to construct a valid request beyond what the schema already provides. This is insufficient for an agent to fully understand the tool's behavior.

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

Parameters3/5

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

The input schema provides 100% coverage for all 5 parameters, so the description need not repeat them. The description adds no extra semantic meaning about how parameters relate to each other (e.g., deviceId required for Device scope), but this is already in the schema. Baseline of 3 is appropriate.

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 tool retrieves historical archive data for a time period, which distinguishes it from the realtime sibling tools. However, it is somewhat generic in not specifying the kind of archive data or the context of the device, though the schema fills in the details.

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?

No explicit guidance is provided on when to use this tool versus alternatives. The word 'historical' implies it should be used for past data rather than realtime, but there is no direct comparison to sibling tools or mention of prerequisites or exclusions.

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

get_inverter_infoC

Get static inverter information

ParametersJSON Schema
NameRequiredDescriptionDefault
deviceIdNoSpecific device ID (optional, defaults to all devices)

TDQS

C2.9/5.0
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, but it only states the operation and nature. It doesn't disclose behavioral traits such as whether it returns data for all devices by default, potential pagination, error behavior, or auth requirements. 'Static' adds minor context but is insufficient.

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 a single, concise sentence without fluff, effectively conveying the core purpose. It could be enriched with more context, but it earns its place and remains appropriately sized.

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?

For a simple tool with one optional parameter and no output schema, the description is minimal but adequate. It clearly states the tool gets static inverter info but leaves the return format and scope details to the schema. Given the sibling context and simplicity, it's complete enough for basic use but has gaps.

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

Parameters3/5

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

The schema already provides a clear description for the single parameter ('Specific device ID (optional, defaults to all devices)'), and coverage is 100%. The tool description adds no additional parameter semantics, so the baseline of 3 applies.

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 uses the specific verb 'Get' with the resource 'static inverter information,' clearly distinguishing it from real-time siblings like get_inverter_realtime via the word 'static.' However, it doesn't mention the optional deviceId parameter that the schema provides, so it's clear but not fully differentiating from other static getters.

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 offers no guidance on when to use this tool versus alternatives. It does not explicitly state that it's for static data or contrast with real-time tools, and there are no exclusions or alternative tool references. The word 'static' only implies usage context.

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

get_inverter_realtimeB

Get real-time inverter data including power, energy, voltage, current

ParametersJSON Schema
NameRequiredDescriptionDefault
deviceIdNoSpecific device ID (optional, defaults to system scope)
dataCollectionNoData collection typeCommonInverterData

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only states 'Get real-time inverter data', implying a read operation but giving no details on caching, rate limits, authentication, or data freshness. The behavioral transparency is minimal beyond what 'get' implies.

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

Conciseness5/5

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

The description is a single sentence of 9 words, front-loaded with the action and resource. Every word contributes to the core message. There is no fluff or repetition.

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?

For a read-only tool with two optional params and no output schema, the description covers the core output fields. However, it doesn't explain the impact of the dataCollection parameter on returned fields, nor any usage context. It is minimally adequate but leaves gaps in how to choose dataCollection or interpret results.

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

Parameters3/5

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

The input schema already provides 100% coverage for both parameters (deviceId and dataCollection) with descriptions. The description adds no additional parameter semantics; it only lists output fields (power, energy, voltage, current). Baseline 3 is appropriate since the schema handles parameter documentation fully.

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 tool's purpose: 'Get real-time inverter data' with specific data types (power, energy, voltage, current). This distinguishes it from siblings like get_inverter_info (static info) and get_meter_realtime (meter data), though it doesn't explicitly name alternatives.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions. The description is a single statement without contextual usage advice, making it insufficient for an agent deciding between this and sibling tools.

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

get_logger_led_infoA

Get logger LED status information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the function without revealing any traits such as output format, read-only guarantees, or potential side effects.

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

Conciseness5/5

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

The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and resource, making it easy to scan.

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 simplicity of the tool (no params, no output schema), the description is adequate but lacks detail about the structure or meaning of the returned LED status information. An agent may need more context to determine if this tool satisfies a specific request.

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 zero parameters, and the schema is trivially complete. Per the baseline for zero-parameter tools, a score of 4 is appropriate since the description does not need to add parameter details.

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?

The description clearly states the tool retrieves logger LED status information, with a specific verb ('Get') and resource. It is distinct from sibling tools like get_system_status and get_inverter_info, which target different data points.

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 offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, intended use cases, or situations where other tools should be preferred.

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

get_meter_realtimeB

Get real-time smart meter data

ParametersJSON Schema
NameRequiredDescriptionDefault
scopeNoData scopeSystem

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states 'real-time data' without mentioning return format, scope handling, defaults, or any side effects (e.g., whether it's read-only). For a get tool, some behavioral transparency is expected, but this is lacking.

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 a single, clear sentence with no unnecessary words. It is well-structured and front-loaded with the core action. However, it is slightly under-specified for a tool with optional parameters, but conciseness per se is good.

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

Completeness2/5

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

Given the lack of output schema and minimal annotations, the description should provide more context about what 'real-time smart meter data' includes and how the scope parameter affects results. The single sentence leaves too many gaps for an agent to use the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100% for the single 'scope' parameter, including an enum and default value. The description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage but does not enhance understanding.

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 a specific verb ('Get') and resource ('real-time smart meter data'), making the primary purpose understandable. However, it does not distinguish this from sibling tools like get_inverter_realtime or get_sensor_realtime, which follow the same naming pattern and analogous descriptions.

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?

The description implies usage for smart meter data, but it does not explicitly state when to choose this tool over others or mention any exclusions. The parameter 'scope' hints at System vs Device, but without guidance on which to use or when, guidance is only implied by the resource name.

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

get_ohmpilot_realtimeA

Get real-time OhmPilot data (smart heating element controller power and temperature)

ParametersJSON Schema
NameRequiredDescriptionDefault
deviceIdNoOhmPilot device ID (optional, defaults to system-wide data)

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the operation is a 'Get' (read-only) and specifies the data fields, but it does not describe the return format, error behavior, or any side effects. The description is minimally transparent but not contradicting.

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

Conciseness5/5

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

The description is a single concise sentence that front-loads the action and resource, with a parenthetical clarifying the specific data types. No unnecessary words or repetition.

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

Completeness4/5

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

For a tool with one optional parameter and no output schema, the description gives enough context to understand the core purpose and data retrieved. It could be improved with details about return structure, but the simplicity of the tool makes it reasonably complete.

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

Parameters3/5

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

The input schema has one parameter with a description that covers its optional nature and default behavior (system-wide data). Schema description coverage is 100%, so the description adds no additional meaning beyond the schema. Baseline of 3 is appropriate.

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?

The description clearly states the tool retrieves real-time OhmPilot data, specifically power and temperature from a smart heating element controller. This is a specific verb+resource combination that distinguishes it from sibling realtime data tools like get_inverter_realtime or get_meter_realtime.

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?

The description does not explicitly state when to use this tool versus alternatives or provide exclusions. The device-specific name implies it is for OhmPilot data, but there is no direct guidance on selection among the many realtime data tools.

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

get_powerflow_realtimeA

Get real-time power flow data showing energy production, consumption, and grid interaction

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of disclosing behavior. The description only repeats 'real-time' and adds data categories; it does not mention read-only status, caching, latency, or any other behavioral traits beyond what the name already implies.

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

Conciseness5/5

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

The description is a single sentence that is front-loaded with the verb and resource, and it efficiently adds value by specifying the data categories. No waste or redundancy.

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?

With no output schema, the description must clarify return values. It mentions production, consumption, and grid interaction, which is a good start, but it lacks details on data structure, units, or update frequency, making it only partially complete for a zero-parameter tool.

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?

There are zero parameters, so the schema completely covers the input. The baseline of 4 for zero-parameter tools applies, as there is no parameter info needed and the description appropriately avoids unnecessary details.

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?

The description clearly states the tool gets real-time power flow data and specifies the key aspects: production, consumption, and grid interaction. This distinguishes it from sibling tools that focus on inverter, meter, sensor, or storage real-time data.

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?

The description implies usage when power flow data is needed, but it does not provide explicit guidance on when to prefer it over other real-time getter tools. No alternatives or exclusions are mentioned, so guidance is only implicit.

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

get_sensor_realtimeB

Get real-time sensor data (temperature, irradiance, wind, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
dataCollectionNoSensor data collection typeNowSensorData

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'real-time' but does not explicitly state that this is a read-only operation, whether it requires authentication, or what side effects (if any) exist. The 'etc.' leaves the exact data content ambiguous.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with parenthetical examples that clarify scope. Every word earns its place; no fluff or redundancy. It is appropriately concise for a simple data retrieval tool.

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

Completeness2/5

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

Given there is no output schema and only one optional parameter, the description should explain what the tool returns and how the parameter alters behavior. It fails to do so—the user does not learn what MinMaxSensorData means or whether the response includes all sensor types. The description is minimally viable but leaves significant gaps.

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

Parameters3/5

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

The input schema covers 100% of the parameter (dataCollection) with a description and enum values, so the baseline is 3. The tool description adds no extra meaning about how dataCollection influences the result; it merely lists example data types without linking them to the parameter.

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?

The description uses a specific verb ('Get') and identifies a clear resource ('real-time sensor data') with concrete examples (temperature, irradiance, wind). This distinguishes it from sibling tools like get_inverter_realtime or get_meter_realtime, which target different device types.

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?

There is no guidance on when to use this tool versus the many sibling real-time data tools. No context about typical scenarios, exclusions, or alternatives is provided. The description merely states what it does without any usage direction.

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

get_storage_realtimeA

Get real-time battery storage data (state of charge, power, temperature)

ParametersJSON Schema
NameRequiredDescriptionDefault
deviceIdNoStorage device ID (optional, defaults to system-wide data)

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions real-time nature and data fields but does not describe error behavior, authentication requirements, or the effect of optional deviceId on output. For a simple read tool, this is minimal but lacks depth.

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

Conciseness5/5

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

The description is a single concise sentence that directly states the tool's purpose and key output data. It is well-structured and free of unnecessary words, every word contributing to the meaning.

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 only one optional parameter and no output schema or annotations, the description provides adequate basic context. However, it does not explain the response format or handle edge cases like invalid deviceId, making it somewhat incomplete but acceptable for a straightforward getter.

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

Parameters3/5

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

The input schema covers the single parameter deviceId with a clear description and default behavior, giving 100% schema coverage. The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline score of 3 applies.

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?

The description clearly states the tool gets real-time battery storage data and lists the specific metrics (state of charge, power, temperature). This distinguishes it from sibling real-time tools like get_inverter_realtime or get_meter_realtime, which target different resources.

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

Usage Guidelines4/5

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

The description provides clear context that this tool is for storage-specific real-time data, implying when to use it. However, it does not explicitly mention alternatives or exclusions, but the resource naming is sufficient to differentiate it from other real-time data tools.

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

get_string_realtimeA

Get real-time DC string data (voltage and current per string)

ParametersJSON Schema
NameRequiredDescriptionDefault
dataCollectionNoString data collection typeNowStringControlData

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It signals a read-only operation through the verb 'Get', and it mentions the data returned (voltage and current). However, it does not explain the behavior of the dataCollection parameter, especially the difference between 'NowStringControlData' and 'LastErrorStringControlData', which could significantly affect what data is returned. This leaves important behavioral details undisclosed.

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

Conciseness5/5

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

The description is a single, succinct sentence that communicates the tool's purpose immediately. It contains no unnecessary words or repetition, making it highly concise and well-structured.

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?

For a simple one-parameter tool with no output schema, the description provides basic context: it returns voltage and current per string. However, it does not clarify the significance of the two dataCollection options, particularly 'LastErrorStringControlData', which might not be 'real-time' as the description claims. This ambiguity leaves a gap in understanding correct usage.

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

Parameters3/5

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

The input schema has 100% coverage for the single parameter, including an enum and default value. The description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 applies. It does not explain the semantics of the enum options, but the schema already describes it as a collection type.

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 tool's function: 'Get real-time DC string data (voltage and current per string)'. It uses a specific verb and resource, and the mention of 'string data' helps differentiate it from sibling real-time tools like inverter or meter. However, it does not explicitly contrast itself with those alternatives, so it falls short of a 5.

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?

The description implies usage context by naming 'DC string data', so an agent can infer when to use it. But it provides no explicit guidance on when to choose this over other real-time tools, no exclusions, and no mentions of prerequisites. The usage is implied rather than clearly spelled out.

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

get_system_statusB

Get system status and logger information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only implies a read-only operation via 'Get' but gives no details about the exact content, authentication requirements, or potential limitations. This is minimal disclosure for a tool with no annotations.

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

Conciseness5/5

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

The description is a single, concise sentence with no redundant words. It is front-loaded with the action and resource, making it easy to parse quickly. Every word earns its place.

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

Completeness2/5

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

With no output schema, no annotations, and no parameter context, the description is the only source of behavioral information. However, it is vague about what 'system status' encompasses and does not position the tool relative to its many siblings. The description is too thin to provide complete context for an agent to fully understand the tool's capabilities.

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 takes no parameters, as indicated by the empty input schema. According to the guidelines, a tool with zero parameters receives a baseline score of 4. The description adds nothing beyond that, but no parameter clarification is needed.

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 verb 'Get' and resource 'system status and logger information' clearly indicate the tool's function. It is specific enough to avoid being a tautology, though it does not explicitly distinguish itself from sibling tools that focus on specific subsystems like inverters or meters.

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 its siblings. There is no mention of what makes this the general status endpoint or when a user should prefer a more specific tool. It simply states what it does without contextualizing it among alternatives.

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

test_connectionA

Test the connection to the Fronius device

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations provided, the description carries the full responsibility for disclosing behavior. It merely states 'Test the connection' but does not explain what the test involves, whether it performs a network call, what the return format is (e.g., boolean, status object), or how errors are handled. This lack of detail leaves the agent uncertain 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.

Conciseness5/5

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

The description is a single, direct sentence that immediately communicates the tool's purpose. It is concise, front-loaded, and contains no filler or redundant information.

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?

For a zero-parameter tool, the description is adequate as a minimum viable explanation, but it lacks details about the outcome or return value. Since there is no output schema, the description should ideally state what the test returns (e.g., success/failure, connection status). This missing information prevents it from being fully complete.

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 zero parameters, so the baseline is 4. The description does not need to add parameter semantics, and the input schema is empty. No additional explanation is required.

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?

The description uses the specific verb 'Test' with the resource 'connection to the Fronius device', clearly distinguishing this tool from the sibling get_* tools that retrieve data. It directly states what the tool does without ambiguity.

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. It does not mention that this is a health check to be run before other operations, nor does it reference any sibling tools. Usage is merely implied by the tool's name and description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 14 tool updatesv1.1.1
    • First observedget_active_devices
    • First observedget_api_version
    • First observedget_archive_data
    • First observedget_inverter_info
    • First observedget_inverter_realtime
    • First observedget_logger_led_info
    • First observedget_meter_realtime
    • First observedget_ohmpilot_realtime
    • First observedget_powerflow_realtime
    • First observedget_sensor_realtime
    • First observedget_storage_realtime
    • First observedget_string_realtime
    • First observedget_system_status
    • First observedtest_connection
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation4/5

Most tools target distinct sub-systems (inverter, meter, powerflow, sensor, storage, string, ohmpilot), making them easy to tell apart. However, get_system_status and get_logger_led_info overlap in scope, and get_active_devices could cause confusion with resource-specific tools.

Naming Consistency4/5

The vast majority of tools follow a get_<resource>_<type> pattern, but test_connection breaks this. Additionally, only inverter has both info and realtime variants, while other resource types only have realtime, creating slight inconsistency across devices.

Tool Count5/5

14 tools is a well-scoped size for a Fronius solar monitoring server, covering all major subsystems without being excessive. Each tool serves a specific data access need.

Completeness4/5

The server provides comprehensive real-time data, historical archive access, and connection testing. However, static info is only available for the inverter, leaving gaps for static information about meter, sensor, storage, and other devices.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MeteoControl MCP Server

    nielsvbrecht
    A
    license
    C
    quality
    D
    maintenance
    An MCP server that enables natural language interaction with the MeteoControl VCOM API v2 for monitoring solar array installations. It allows users to retrieve real-time and historical energy data, system alerts, and detailed asset configuration metrics.
    4
    Apache 2.0

  • Tigo Energy MCP Server

    matt-dreyer
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol (MCP) server that provides comprehensive access to Tigo Energy solar system data and analytics. It enables AI assistants to interact with your Tigo solar monitoring system to retrieve production data, performance metrics, system health information, and maintenance insights.
    MIT

  • fronius-mcp

    flowiesner
    A
    license
    A
    quality
    D
    maintenance
    Enables real-time solar data from Fronius inverters via Claude, allowing natural language queries about solar production, battery, and grid exchange.
    5
    1
    Apache 2.0

  • mcp-fsolar

    RicardoSantos
    A
    license
    A
    quality
    A
    maintenance
    MCP server that connects to Felicity Solar cloud battery data, allowing natural language queries about battery status, cell voltages, and charge state.
    17
    22
    MIT

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/huber/fronius-mcp-server'

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