A
licenseA
qualityB
maintenanceMCP server for the Australian Energy Market Operator (AEMO) National Electricity Market. Plain-English access to 5-min dispatch prices, regional demand, interconnector flows, generation by fuel, rooftop PV.
5
MIT
solarnetwork-mcp
by hoodsy
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@solarnetwork-mcpshow me the latest solar generation data"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
solarnetwork-mcp
Read-only MCP server for SolarNetwork — query solar generation, consumption, and other DER telemetry over the SolarQuery API. Zero config against a public demo node. Public (/pub) mode only; authenticated (sec) mode is not implemented.
Setup
npm install
npm run build
npm test # offline, against captured fixtures
npm run smoke # live check against demo node 108MCP client config (stdio):
{
"mcpServers": {
"solarnetwork": {
"command": "node",
"args": ["/path/to/solarnetwork-mcp/dist/index.js"]
}
}
}Related MCP server: Victron VRM MCP Server
Tools
Tool | Answers |
| What date range has data? (call first) |
| Which source IDs exist? |
| Most recent datum per source |
| Time series between two node-local dates (Day/Hour/Month; raw guarded) |
| Energy used/generated over a period |
Responses are compact { data, meta } JSON; meta reports count, truncated, and paging. Day aggregation by default, 500-row cap, raw queries over 7 days require allowRaw.
Demo node
Node 108 — public, posting since 2013, time zone Pacific/Auckland. Sources: DB (bidirectional meter, richest stream), Main (intermittent), A/B/C (phase watts), OfficeTemp (dormant). A complete month to query: June 2026.
Environment
Variable | Default |
|
|
| unset; sec mode is unimplemented and the server fails fast if they are set |
Available Tools
5 toolsget_latestMost recent datumARead-only
What is the most recent datum for each of a node's sources, and when was it recorded? Values are the device's own property map (e.g. watts, wattHours) passed through as-is — property names are the only unit hints; do not invent units. Sources silent for ~90 days are omitted unless you pass sinceDate to look further back.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | SolarNetwork node ID (public demo node: 108) | |
| sinceDate | No | UTC date to look back to; without it the API only considers the last ~90 days | |
| sourceIds | No | Source IDs to include; omit for all |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: values are pass-through property maps with unit hints from names, silent source behavior, and sinceDate override. No contradiction with readOnlyHint or openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences with front-loaded purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficiently explains return format and key constraints, though lacks mention of pagination or response structure. Adequate given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 3 parameters (100% coverage). Description adds behavioral context but minimal extra meaning for individual parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the most recent datum per source with timestamp, and distinguishes from siblings like query_datum (historical) and get_meter_reading (aggregate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use sinceDate to bypass the ~90-day silent source filter, but does not mention alternative tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_meter_readingMeter reading over a periodARead-only
How much energy (or any accumulating meter property, e.g. wattHours) was used or generated between two node-local dates? Computes a meter-style difference between readings nearest the period boundaries — the natural fit for 'total for June'. Each row shows the difference plus the _start/_end raw readings; only sources with accumulating properties appear.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | SolarNetwork node ID (public demo node: 108) | |
| endDate | Yes | Node-local end, exclusive | |
| sourceId | No | Single source ID; omit to get one reading per source that has accumulating properties | |
| startDate | Yes | Node-local start, inclusive (YYYY-MM-DD or YYYY-MM-DDTHH:mm) |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond readOnlyHint and openWorldHint by explaining the nearest-reading computation, inclusion of _start/_end readings, and that only accumulating properties appear, providing valuable behavioral insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Packs significant detail into a single paragraph; efficient but could benefit from bullet points for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: computation logic, output structure, and source filtering, but omits details on result limits, error handling, or timezone specifics given the absence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaningful context beyond schema: node-local dates, inclusive/exclusive boundaries, example demo node ID, and behavior when sourceId is omitted, fully compensating for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes a meter-style difference for accumulating properties over a date range, distinguishing it from siblings like query_datum or get_latest by focusing on totals for a period.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context (e.g., 'natural fit for total for June') but does not explicitly compare to siblings or state when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reportable_intervalReportable date rangeARead-only
What date range does a node have data for? Call this first for an unfamiliar node so you never query an empty range. Returns startDate/endDate in the node's local time zone, the timeZone name, and day/month/year counts.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | SolarNetwork node ID (public demo node: 108) | |
| sourceId | No | Optional source ID to limit the interval to |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds return details: startDate/endDate in local time zone, timeZone name, and counts. This goes beyond annotations and provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste: first states purpose, second gives usage guidance, third lists return values. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with annotations, the description covers purpose, usage, and return format. Could mention error handling for non-existent nodes, but overall adequate for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions (nodeId with demo note, sourceId optional). The description doesn't add new parameter meanings but reinforces the context of unfamiliar nodes and avoiding empty queries, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the date range for which a node has data, using specific verb and resource. It distinguishes from siblings by advising to call this first for unfamiliar nodes to avoid querying empty ranges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this first for an unfamiliar node so you never query an empty range,' giving clear when-to-use guidance. It does not explicitly mention when not to use, but the instruction is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sourcesList source IDsARead-only
Which data streams (source IDs) does a node have? Without a date window this lists every source that ever posted — including long-dead ones — so pass a UTC window to see only sources active in that period.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | SolarNetwork node ID (public demo node: 108) | |
| endDate | No | Optional UTC end (YYYY-MM-DD), exclusive | |
| startDate | No | Optional UTC start (YYYY-MM-DD) to only list sources active in a window |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true and openWorldHint=true. The description adds value by warning about long-dead sources and clarifying that a date window filters for active sources only. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with a question, and zero waste. Every word serves a purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and behavior well, but does not specify the format of returned data (e.g., array of strings, object). Since there is no output schema, additional detail about the response structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with basic descriptions. The description adds semantic value by explaining that startDate and endDate define a UTC window for active sources, which is not fully captured in the schema's pattern descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description poses a clear question ('Which data streams... does a node have?') and contrasts behavior with and without date window. It distinguishes from sibling tools like query_datum and get_meter_reading by focusing solely on listing source IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly advises using a date window to see active sources, but does not explicitly compare against sibling tools or state when not to use this tool. The context is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_datumQuery time seriesARead-only
Time series for a node between two node-local dates (end exclusive) — answers 'how much / what pattern over time'. Default Day aggregation gives one row per source per day; Hour suits intra-day shape (the API silently coarsens Hour to Day beyond 32 days); None returns raw samples and is refused over 7 days unless allowRaw=true. Responses are capped at 500 rows — when meta.truncated is true, page with offset.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | SolarNetwork node ID (public demo node: 108) | |
| offset | No | Row offset for paging when a previous call was truncated | |
| endDate | Yes | Node-local end, exclusive | |
| allowRaw | No | Required to run aggregation=None over ranges longer than 7 days | |
| sourceIds | No | Source IDs to include; omit for all | |
| startDate | Yes | Node-local start, inclusive (YYYY-MM-DD or YYYY-MM-DDTHH:mm) | |
| aggregation | No | Bucket size; None = raw samples (guarded, see allowRaw) | Day |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behaviors: response cap at 500 rows with pagination via offset, silent coarsening of Hour aggregation, and refusal of None aggregation without allowRaw. Consistent with readOnlyHint and openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences pack purpose, aggregation guidelines, and pagination detail. Front-loaded purpose with clear, scannable structure. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: date range, aggregation options, row limit, and pagination. Lacks explicit output schema description, but given openWorldHint and focus on input constraints, it is sufficiently complete for its use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds value by explaining aggregation behavior and allowRaw necessity, beyond the schema's enum descriptions. Does not repeat schema info unnecessarily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries time series data for a node between dates, answering 'how much / what pattern over time'. It distinguishes from sibling tools like get_latest or list_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on aggregation levels (Day, Hour, None) and conditions (Hour coarsens beyond 32 days, None requires allowRaw for >7 days). Lacks explicit comparison to sibling tools but offers practical usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.4/5.0
Disambiguation4/5
Tools have distinct purposes: obtaining date ranges, listing sources, retrieving latest data, querying time series, and computing meter readings. Minor potential overlap between query_datum and get_meter_reading is clarified by descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., get_reportable_interval, list_sources) with underscores, ensuring predictability.
Tool Count5/5
Five tools cover the essential operations for a solar network data API without being excessive or insufficient, well-scoped for the purpose.
Completeness4/5
The tools cover data availability, source listing, latest data, time series queries, and meter readings. Minor gaps like source metadata are absent but acceptable for a read-only API.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Public, read-only MCP server for FarmNeural company facts, packages, and capabilities.
MCP server wrapping the Tesla Fleet API and TeslaMate API
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Related MCP Servers
- AlicenseBqualityDmaintenanceRead-only MCP server integrating with the Victron VRM API to monitor solar systems, batteries, alarms, and more.41256MIT
- AlicenseNot gradedqualityAmaintenanceA read-only MCP server for querying telemetry data from configurable backends. Provides tools to list sources, describe schemas, run bounded queries, and compute aggregates.MIT
- AlicenseAqualityCmaintenanceA lean Model Context Protocol (MCP) server that gives AI assistants like Claude structured access to a SolarEdge PV installation via the official SolarEdge Monitoring API.4MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoodsy/solarnetwork-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server