MeteoControl VCOM API v2를 위한 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 확장을 통해 Gemini CLI를 사용하여 자연어로 태양광 발전소를 모니터링하고, 에너지 생산 데이터를 조회하며, 시스템 상태 점검을 수행할 수 있습니다.
시스템 탐색: 계정과 연결된 모든 태양광 시스템을 나열합니다.
에너지 모니터링: 과거 에너지 생산 데이터(Wh/kWh/MWh)를 조회합니다.
자산 정보: 패널, 인버터 및 현장 용량에 대한 기술적 세부 정보를 가져옵니다.
실시간 전력: 즉각적인 AC 전력 출력을 확인합니다.
다중 전송 지원: 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에게 태양광 시스템에 대해 물어볼 수 있습니다:
"내 태양광 시스템 목록을 보여줘."
"지난 24시간 동안 [systemKey] 시스템의 에너지 생산량은 얼마야?"
"[systemKey] 시스템의 INV1에 대한 기술적 세부 정보를 보여줘."
공유 MCP 서버를 사용하는 경우, 프롬프트에 직접 자격 증명을 제공하거나 로컬에서 구성할 수 있습니다. 도구는 선택적 apiKey, user, password 인수를 허용합니다.
/health [systemKey]: 포괄적인 현장 상태 점검을 수행합니다.
/yield [systemKey]: 에너지 생산 데이터를 조회하고 요약합니다.
이 서버는 여러 작동 모드를 지원합니다:
Gemini CLI에서 사용하는 기본 모드입니다.
명령어: node dist/index.js
설정: command와 args를 사용하여 gemini-extension.json에 정의됩니다.
여러 사용자를 위해 중앙 서버에서 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: 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
