一个用于 MeteoControl VCOM API v2 的模型上下文协议 (MCP) 服务器。此扩展允许您通过 Gemini CLI 使用自然语言监控太阳能阵列、检索能源生产数据并执行系统健康检查。
系统发现： 列出与您的账户关联的所有太阳能系统。
能源监控： 检索历史能源生产数据 (Wh/kWh/MWh)。
资产信息： 获取有关面板、逆变器和站点容量的技术细节。
实时功率： 检查瞬时交流功率输出。
多传输支持： 通过 Stdio 本地运行或通过 SSE 远程托管。
多租户 (BYOC)： 在共享环境中支持“自带凭据”。
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 询问有关您的太阳能系统的问题：
“列出我的太阳能系统。”
“系统 [systemKey] 过去 24 小时的能源产量是多少？”
“向我展示系统 [systemKey] 中 INV1 的技术细节。”
如果您使用的是共享 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=your_generated_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：您的 VCOM API 密钥。
METEOCONTROL_USER：您的 VCOM 用户名（电子邮件）。
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
