Un servidor del Protocolo de Contexto de Modelo (MCP) para la API v2 de MeteoControl VCOM. Esta extensión le permite monitorizar paneles solares, recuperar datos de producción de energía y realizar comprobaciones del estado del sistema utilizando lenguaje natural a través de la CLI de Gemini.
Descubrimiento de sistemas: Enumere todos los sistemas solares asociados a su cuenta.
Monitorización de energía: Recupere datos históricos de producción de energía (Wh/kWh/MWh).
Información de activos: Obtenga detalles técnicos sobre paneles, inversores y capacidad del sitio.
Potencia en tiempo real: Compruebe la potencia de salida de CA instantánea.
Soporte de transporte múltiple: Ejecute localmente a través de Stdio o aloje remotamente a través de SSE.
Multi-inquilino (BYOC): Soporte para "Traiga sus propias credenciales" (Bring Your Own Credentials) en un entorno compartido.
Related MCP server: Tigo Energy MCP Server
Para instalar la extensión directamente desde GitHub:
gemini extensions add https://github.com/your-org/meteocontrol-mcpClone el repositorio:
git clone https://github.com/your-org/meteocontrol-mcp.git
cd meteocontrol-mcpInstale las dependencias y compile:
npm install
npm run buildUna vez instalado, puede preguntar a Gemini sobre sus sistemas solares:
"Enumera mis sistemas solares."
"¿Cuál es la producción de energía del sistema [systemKey] en las últimas 24 horas?"
"Muéstrame los detalles técnicos de INV1 en el sistema [systemKey]."
Si está utilizando un servidor MCP compartido, puede proporcionar sus propias credenciales directamente en sus prompts o configurarlas localmente. Las herramientas aceptan argumentos opcionales apiKey, user y password.
/health [systemKey]: Realice una comprobación completa del estado del sitio.
/yield [systemKey]: Recupere y resuma los datos de producción de energía.
El servidor admite múltiples modos de funcionamiento:
Este es el modo predeterminado utilizado por la CLI de Gemini.
Comando: node dist/index.js
Configuración: Definido en gemini-extension.json usando command y args.
Utilice este modo para alojar el servidor MCP en un servidor central para múltiples usuarios.
El modo remoto requiere un MCP_SERVER_TOKEN obligatorio por seguridad. Puede generar un token seguro usando:
openssl rand -base64 32Variables de entorno:
MCP_TRANSPORT=sse
MCP_SERVER_TOKEN=su_token_generado (Requerido)
PORT=3000 (opcional, el valor predeterminado es 3000)
Comando de ejecución:
MCP_TRANSPORT=sse MCP_SERVER_TOKEN=your_token node dist/index.jsPuede ejecutar el servidor como un contenedor para un despliegue sencillo.
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:latestEn su archivo local .gemini/settings.json, añada la url y la cabecera Authorization:
{
"mcpServers": {
"meteocontrol": {
"url": "https://your-mcp-server.com/sse",
"headers": {
"Authorization": "Bearer your_generated_token"
}
}
}
}Las siguientes variables de entorno son necesarias para que el servidor se comunique con MeteoControl (a menos que se proporcionen credenciales por solicitud):
METEOCONTROL_API_KEY: Su clave de API de VCOM.
METEOCONTROL_USER: Su nombre de usuario de VCOM (correo electrónico).
METEOCONTROL_PASSWORD: Su contraseña de VCOM.
Licencia Apache 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
