solarnetwork
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_sourcesA | List the streams reporting on a SolarNetwork node, classified by what they measure: GEN (site generation meter), INV (individual inverter), PYR (pyranometer, i.e. solar irradiance), WEA (weather). Also returns the node's data window and timezone. Always start here when you do not already know what a node measures. |
| get_latestA | Get the most recent reading for each source on a node, including weather and irradiance where available. Use this for 'what is happening right now' and to check whether a stream is still live. Note that generation is legitimately zero at night. |
| query_datumA | Query time-series data over a date range, rolled up by an aggregation period. Accepts multiple nodes at once. Returns one series per source with mean power, total energy and mean irradiance. Use Day for week-to-month questions, Hour or FifteenMinute to inspect a single day's shape, and Month for year-scale trends. Note that |
| get_energyA | Get true accumulated energy (watt-hours) between two dates from meter readings, rather than averaging instantaneous power. Use this for 'how much did this site generate' questions, and for anything reporting- or billing-shaped, because averaging watts loses accuracy on accumulating properties. |
| diagnose_siteA | Diagnose a solar site over a date range by comparing each inverter against its own siblings, with irradiance as the weather control. Distinguishes a dead inverter (reporting but producing zero) from a reporting gap (producing but not reporting) from ordinary bad weather (everything down, irradiance also down). This is the right tool for 'is anything wrong at this site', 'which inverter is broken', or 'why did output drop'. |
| compare_fleetA | Compare several nodes over the same date range and rank them by output, in a single query. Use for portfolio-level questions: which sites are underperforming, how does this site compare to the rest, which node should I look at first. |
| get_anomaliesA | Read the output of the platform's own ML anomaly detector for a node, where one is published. Each reading carries the predicted value, the actual value, the error between them, the irradiance at the time and an ANOMALY/NOMINAL status. Use this when you want the platform's own verdict rather than computing one yourself, and to cross-check what diagnose_site concluded. Node 392 is a public example. |
| asset_reviewA | Walk a site's day-by-day record and return every fault as a dated event: what broke, when it started, when it ended, how long it ran and how much energy it cost. Use this for 'what is wrong with this site', 'when did it start', 'how much has this cost us' and anything feeding a work order. Prefer this over diagnose_site for any window longer than a few days: diagnose_site reduces each source to one window mean, so a fault that started or ended part way through is invisible to it. Detection is peer-relative, so bad weather never raises an event. |
| create_service_reportA | Turn a site's faults into a service request that a person can act on: prioritised jobs, each with what happened in plain language, the evidence behind it, numbered steps for site, the tools needed and explicit sign-off criteria. Runs asset_review internally, so call this directly rather than reviewing first. Use format 'pdf' for a printable field pack, 'markdown' to paste into a ticket, or 'json' to post-process. |
| list_public_nodesA | List SolarNetwork nodes known to be readable without credentials, from a catalogue built by scanning node IDs 1-5000. Use this first when you do not have a node ID in hand, since there is no public endpoint that enumerates nodes. Filter to live nodes to avoid ones that stopped reporting years ago. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools target clearly distinct purposes: discovery, latest reading, aggregated time-series, true energy, quick diagnosis, fleet ranking, ML verdicts, event history, reporting, and node discovery. Two close pairs (query_datum/get_energy and diagnose_site/asset_review) overlap enough that agents could pick the wrong one, but the descriptions explicitly steer usage, keeping misselection risk low.
Names are uniformly lowercase snake_case and mostly follow a verb_noun pattern (list_sources, get_energy, diagnose_site, create_service_report). Minor deviations: get_latest uses an adjective as the object, and asset_review inverts the verb_noun order, but all names remain easily parseable and predictable.
Ten tools is squarely in the well-scoped range for a solar monitoring domain. Each tool earns its place: two for discovery, one for live status, two for historical data access, three for the diagnostics cluster, one for fleet comparison, and one for report generation. No redundant or filler tools.
The set covers the full analysis lifecycle: discovering public nodes, enumerating sources, reading current state, querying both averaged and true energy, diagnosing faults at both quick and event-level granularity, cross-checking with ML output, comparing sites, and producing serviceready reports. Minor gaps include no raw non-aggregated datum access and no site metadata endpoint, but core workflows have no dead ends.