heliograph
OfficialServer 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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| heliograph_doctorA | Check whether the transport works from here, and change nothing. Run this before a long step: read access is not write access, and finding out afterwards costs a whole round trip through somebody who cannot debug the machine. |
| heliograph_estatesA | List the configured estates and the transport each uses. Call this first when you do not know which estate to act on. |
| heliograph_gapsA | Where a run stalled. Returns the intervals in the log's timestamp column, longest first, each attributed to the line BEFORE it, which is what was running. Do this before reading a long log: a hang and slow progress are indistinguishable without it. If every line carries the same timestamp the capture was buffered and the log cannot answer the question at all, which this reports as an error. |
| heliograph_logsA | List the captured logs, newest first. Each name carries the request id that produced it, so the log for a run you sent is the one whose name matches the id heliograph_send returned. Use this to find a log; use heliograph_read_log to read one. |
| heliograph_read_logA | Read a captured log whole. Every line carries a UTC timestamp. Read all of it, including the parts that worked: a passing probe beside a failing one is the control that says what the failure means. A green exit means the probes that ran passed, not that the work happened. |
| heliograph_sendA | Publish a step for the station to run, and return immediately. This does NOT wait for the result: poll heliograph_status until it reports a terminal state, then read the log. The station decides whether to run it at all: a step that declares no mode is refused, and one that changes state needs CONFIRM=yes and a station started with --allow-actions. |
| heliograph_statusA | What the station is doing now. State is one of running, idle, cancelled, refused or stopped. An empty state means the station has published nothing yet, which usually means it has not been started. |
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 7 tools
Each tool targets a distinct concern: transport health, estate discovery, stall analysis, log listing, log reading, step submission, and station state. The only closely related pair, logs and read_log, is clearly split into finding vs reading, and gaps is explicitly positioned as a precursor to reading a long log.
All names share the heliograph_ prefix and snake_case, but the pattern is mixed: most are nouns (estates, logs, gaps, status) while send and read_log are verb-based. This is readable but not as predictable as a uniform verb_noun convention.
Seven tools cover the observable workflows of the server without bloat. Each tool has a clear rationale: doctor, estates, send, status, logs, read_log, and gaps all earn their place.
The core lifecycle is well covered: discover estates, check transport, send a step, poll status, identify stalls, and find and read the resulting log. Minor gaps exist around operational controls such as explicitly cancelling a run or managing estate configuration, but these do not block the main described workflow.