Ein Model Context Protocol (MCP)-Server für die MeteoControl VCOM API v2. Diese Erweiterung ermöglicht es Ihnen, Solaranlagen zu überwachen, Energieerzeugungsdaten abzurufen und Systemzustandsprüfungen mittels natürlicher Sprache über die Gemini CLI durchzuführen.
Systemerkennung: Auflistung aller mit Ihrem Konto verknüpften Solarsysteme.
Energieüberwachung: Abruf historischer Energieerzeugungsdaten (Wh/kWh/MWh).
Anlageninformationen: Technische Details zu Modulen, Wechselrichtern und Anlagenkapazität abrufen.
Echtzeit-Leistung: Überprüfung der momentanen AC-Ausgangsleistung.
Multi-Transport-Unterstützung: Lokal über Stdio ausführen oder remote über SSE hosten.
Multi-Tenant (BYOC): Unterstützung für "Bring Your Own Credentials" in einer gemeinsam genutzten Umgebung.
Related MCP server: Tigo Energy MCP Server
Um die Erweiterung direkt von GitHub zu installieren:
gemini extensions add https://github.com/your-org/meteocontrol-mcpKlonen Sie das Repository:
git clone https://github.com/your-org/meteocontrol-mcp.git
cd meteocontrol-mcpInstallieren Sie die Abhängigkeiten und erstellen Sie den Build:
npm install
npm run buildSobald die Installation abgeschlossen ist, können Sie Gemini nach Ihren Solarsystemen fragen:
"List my solar systems."
"What is the energy production for system [systemKey] for the last 24 hours?"
"Show me the technical details for INV1 in system [systemKey]."
Wenn Sie einen gemeinsam genutzten MCP-Server verwenden, können Sie Ihre eigenen Anmeldedaten direkt in Ihren Prompts angeben oder lokal konfigurieren. Die Tools akzeptieren optionale Argumente für apiKey, user und password.
/health [systemKey]: Führt eine umfassende Zustandsprüfung der Anlage durch.
/yield [systemKey]: Ruft Energieerzeugungsdaten ab und fasst diese zusammen.
Der Server unterstützt mehrere Betriebsmodi:
Dies ist der Standardmodus, der von der Gemini CLI verwendet wird.
Befehl: node dist/index.js
Einrichtung: Definiert in gemini-extension.json unter Verwendung von command und args.
Verwenden Sie diesen Modus, um den MCP-Server für mehrere Benutzer auf einem zentralen Server zu hosten.
Der Remote-Modus erfordert aus Sicherheitsgründen ein obligatorisches MCP_SERVER_TOKEN. Sie können ein sicheres Token wie folgt generieren:
openssl rand -base64 32Umgebungsvariablen:
MCP_TRANSPORT=sse
MCP_SERVER_TOKEN=your_generated_token (Erforderlich)
PORT=3000 (optional, Standardwert ist 3000)
Ausführungsbefehl:
MCP_TRANSPORT=sse MCP_SERVER_TOKEN=your_token node dist/index.jsSie können den Server zur einfachen Bereitstellung als Container ausführen.
docker run -i --rm \
-e METEOCONTROL_API_KEY=your_key \
-e METEOCONTROL_USER=your_user \
-e METEOCONTROL_PASSWORD=your_password \
ghcr.io/your-org/meteocontrol-mcp:latestdocker run -d \
-p 3000:3000 \
-e MCP_TRANSPORT=sse \
-e MCP_SERVER_TOKEN=your_token \
-e METEOCONTROL_API_KEY=your_key \
-e METEOCONTROL_USER=your_user \
-e METEOCONTROL_PASSWORD=your_password \
ghcr.io/your-org/meteocontrol-mcp:latestFügen Sie in Ihrer lokalen .gemini/settings.json die url und den Authorization-Header hinzu:
{
"mcpServers": {
"meteocontrol": {
"url": "https://your-mcp-server.com/sse",
"headers": {
"Authorization": "Bearer your_generated_token"
}
}
}
}Die folgenden Umgebungsvariablen sind erforderlich, damit der Server mit MeteoControl kommunizieren kann (sofern keine Anmeldedaten pro Anfrage bereitgestellt werden):
METEOCONTROL_API_KEY: Ihr VCOM API-Schlüssel.
METEOCONTROL_USER: Ihr VCOM-Benutzername (E-Mail).
METEOCONTROL_PASSWORD: Ihr VCOM-Passwort.
Apache License 2.0
| Name | Required | Description | Default |
|---|---|---|---|
| systemKey | Yes | The unique key/ID of the solar system. | |
| apiKey | No | Optional: MeteoControl API Key (if not set on server) | |
| user | No | Optional: MeteoControl Username (if not set on server) | |
| password | No | Optional: MeteoControl Password (if not set on server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| systemKey | Yes | The unique key/ID of the solar system. | |
| apiKey | No | Optional: MeteoControl API Key (if not set on server) | |
| user | No | Optional: MeteoControl Username (if not set on server) | |
| password | No | Optional: MeteoControl Password (if not set on server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| systemKey | Yes | The unique key/ID of the solar system. | |
| from | Yes | The start date and time (ISO 8601). | |
| to | Yes | The end date and time (ISO 8601). | |
| apiKey | No | Optional: MeteoControl API Key (if not set on server) | |
| user | No | Optional: MeteoControl Username (if not set on server) | |
| password | No | Optional: MeteoControl Password (if not set on server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Optional: MeteoControl API Key (if not set on server) | |
| user | No | Optional: MeteoControl Username (if not set on server) | |
| password | No | Optional: MeteoControl Password (if not set on server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_alertsget_asset_infoget_energy_datalist_systemsEach tool has a clearly distinct purpose: get_alerts retrieves alerts, get_asset_info provides asset details, get_energy_data handles energy data, and list_systems lists systems. There is no overlap or ambiguity between these functions, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun pattern with 'get_' or 'list_' prefixes, using snake_case uniformly. This predictable naming scheme enhances readability and reduces confusion for agents.
With 4 tools, the count is reasonable for a server focused on meteorological control, but it feels slightly thin for comprehensive coverage. It includes core functions like alerts, assets, energy data, and systems, but might benefit from additional tools for broader operations.
The tools cover key read operations (get and list), but there are notable gaps in CRUD coverage, such as missing create, update, or delete functions for alerts, assets, energy data, or systems. This could limit agents in performing full lifecycle management tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Hosted MCP server for live public-data APIs and Skills for AI agents.
AI-powered incident management and server monitoring via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nielsvbrecht/meteocontrol-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
