Сервер протокола Model Context Protocol (MCP) для API MeteoControl VCOM v2. Это расширение позволяет вам отслеживать солнечные электростанции, получать данные о выработке энергии и выполнять проверки работоспособности системы с помощью естественного языка через Gemini CLI.
Обнаружение систем: Список всех солнечных систем, связанных с вашей учетной записью.
Мониторинг энергии: Получение исторических данных о выработке энергии (Вт·ч/кВт·ч/МВт·ч).
Информация об активах: Получение технических деталей о панелях, инверторах и мощности площадки.
Мощность в реальном времени: Проверка мгновенной выходной мощности переменного тока.
Поддержка нескольких транспортов: Запуск локально через Stdio или удаленно через SSE.
Мультиарендность (BYOC): Поддержка использования собственных учетных данных (Bring Your Own Credentials) в общей среде.
Related MCP server: Tigo Energy MCP Server
Чтобы установить расширение напрямую из GitHub:
gemini extensions add https://github.com/your-org/meteocontrol-mcpКлонируйте репозиторий:
git clone https://github.com/your-org/meteocontrol-mcp.git
cd meteocontrol-mcpУстановите зависимости и выполните сборку:
npm install
npm run buildПосле установки вы можете спрашивать Gemini о своих солнечных системах:
"List my solar systems." (Список моих солнечных систем)
"What is the energy production for system [systemKey] for the last 24 hours?" (Какова выработка энергии для системы [systemKey] за последние 24 часа?)
"Show me the technical details for INV1 in system [systemKey]." (Покажи мне технические детали для INV1 в системе [systemKey].)
Если вы используете общий MCP-сервер, вы можете предоставить свои собственные учетные данные непосредственно в запросах или настроить их локально. Инструменты принимают необязательные аргументы apiKey, user и password.
/health [systemKey]: Выполнение комплексной проверки работоспособности площадки.
/yield [systemKey]: Получение и обобщение данных о выработке энергии.
Сервер поддерживает несколько режимов работы:
Это режим по умолчанию, используемый Gemini CLI.
Команда: node dist/index.js
Настройка: Определяется в gemini-extension.json с использованием command и args.
Используйте этот режим для размещения MCP-сервера на центральном сервере для нескольких пользователей.
Удаленный режим требует обязательного MCP_SERVER_TOKEN для безопасности. Вы можете сгенерировать безопасный токен с помощью:
openssl rand -base64 32Переменные окружения:
MCP_TRANSPORT=sse
MCP_SERVER_TOKEN=ваш_сгенерированный_токен (обязательно)
PORT=3000 (необязательно, по умолчанию 3000)
Команда запуска:
MCP_TRANSPORT=sse MCP_SERVER_TOKEN=your_token node dist/index.jsВы можете запустить сервер как контейнер для простого развертывания.
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:latestВ вашем локальном файле .gemini/settings.json добавьте url и заголовок Authorization:
{
"mcpServers": {
"meteocontrol": {
"url": "https://your-mcp-server.com/sse",
"headers": {
"Authorization": "Bearer your_generated_token"
}
}
}
}Для взаимодействия сервера с MeteoControl требуются следующие переменные окружения (если учетные данные не предоставляются в каждом запросе):
METEOCONTROL_API_KEY: Ваш API-ключ VCOM.
METEOCONTROL_USER: Ваше имя пользователя VCOM (email).
METEOCONTROL_PASSWORD: Ваш пароль VCOM.
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
