Allows using a Git repository as the transport for sending commands to a remote machine and receiving timestamped execution logs, including gap analysis for stalls.
Remote, captured, auditable execution on a machine you cannot log into
A free, open-source tool by DBHQ
Early, and working. The CLI drives a real station over four transports.
control CLI over git | works, tested end to end against a stock station |
| works |
file share, bundle | work |
MCP server ( | works |
relay | works: dbhq-uk/heliograph-relay, deployed to the Cloudflare edge |
documentation site | |
object store | designed, not built |
The far side is dbhq-uk/heliograph-skill, which is complete and in use. This CLI drives it unmodified - if you already run heliograph, this works against what you have today.
Related MCP server: core-agent-mcp
# Linux and macOS, from a release
curl -sSL https://github.com/dbhq-uk/heliograph/releases/latest/download/heliograph-linux-amd64 \
-o /usr/local/bin/heliograph && chmod +x /usr/local/bin/heliograph
# or from source
go install github.com/dbhq-uk/heliograph/cmd/heliograph@latestA single static binary, no runtime. Checksums are published with each release.
heliograph init payments --dir ~/transport/payments # git, the default
heliograph init ops --transport share --dir /mnt/ops --scope dns
heliograph init air --transport bundle --dir ~/bundles
heliograph plant # what to send the operator
heliograph send net-probe HOSTS="sql01 sql02" # publish a request
heliograph watch # follow it
heliograph logs --last # read the whole log
heliograph logs --last --gaps # where it stalled
heliograph doctor # will this work from here
heliograph mcp # serve all of the above as toolsFor an agent, heliograph mcp is the same CLI as typed MCP tools - one command
to configure, nothing extra to install:
claude mcp add heliograph -- heliograph mcpThe gates do not move. A tool call publishes a request; the station still decides whether to run it. An MCP client asks, it does not get to answer.
--gaps is the one worth knowing about. "Scan the timestamp column for gaps
before reading the content" is the most valuable instruction in the method, and
it has always been a discipline somebody has to remember. It is arithmetic:
$ heliograph logs --last --gaps
demo-20260906T183628Z.txt
5 captured lines
1 interval(s) of 10s or more, longest first.
Each is attributed to the line BEFORE it, which is what was running.
3m12s after 09:14:02 | Refreshing state...The gap belongs to the line before it: the stamp on a line is when that line was produced, so a long interval means the operation named on the preceding line is what took the time.
Someone can reach the machine. You cannot, and you are the one who knows what to ask it. heliograph runs that gap as a loop rather than a relay: you push a step, it runs on the far side, and the whole run comes back as a log with every line timestamped in UTC, whether it passed or failed.
Three components:
control | your machine: the |
transport | the channel: git, relay, object store, file share, bundle |
station | the far side: the box, and the loop running on it |
heliograph-skill is the skill
and its bash toolkit. Plain bash, no interpreter, no packages, nothing to
install on the far side. That single constraint is what lets it run on a
locked-down box where installing anything is its own change request, and it is
the entire proposition.
This product adds Go, a release pipeline, a web build and a cryptographic dependency. None of those belong in a repository whose promise is "plain bash, you can read it before you run it" - not because they would break it by argument, but because they would erode it by proximity. The next person reading that repo would have to work out which half they were looking at.
So the boundary between the two repositories is the gap itself:
| the far side. Bash and PowerShell, zero dependencies, the method |
| the near side. Go CLI, relay server, transports, site |
No Go will ever be added to heliograph-skill. If something here needs a
change over there, it goes as a PR on its own merits, and it is bash.
A control CLI. A single static Go binary. init, plant, send, watch,
logs, doctor. logs --gaps computes inter-line deltas and prints the
outliers, which turns "scan the timestamp column for gaps" from a discipline
you have to remember into a feature.
A relay. The flagship. Both sides dial out over ordinary HTTPS, so an estate needs no git host, no storage account and no VNet. Hosted, and self-hostable from the same binary.
The relay cannot read your logs, and cannot make a station run anything.
That second half is the one that matters: a relay able to forge a request would
be code execution inside every estate at once, which is a far worse position
than any disclosure. Content is end-to-end encrypted with keys the relay never
holds, and every message is signed. Nothing bespoke -
age primitives plus Ed25519. The full account,
including what DBHQ can and cannot honestly claim, is in
docs/specs/2026-09-06-relay-encryption-design.md.
More transports. Generic object store (S3-compatible), a mounted file share, and a signed bundle for a true air gap - all behind one interface, so the read-only gates live in one place and cannot drift per transport.
A documentation site, at heliograph.dbhq.uk.
Give you access you do not have. It does not tunnel, proxy or hold a connection open to a host you control, and there is nothing here to punch through a firewall with. A raw TCP transport was considered and dropped for exactly that reason: a persistent reverse connection is a C2 channel by any blue team's definition, and that sentence is a large part of why this class of tool is permitted in regulated estates.
Every command runs on the far side because someone with legitimate access chose to run it.
cmd/heliograph/ the control CLI, and `heliograph mcp`
cmd/heliograph-seal/ key generation for the relay transport
cmd/heliograph-site/ the static site generator
internal/transport/ git | relay | share | bundle
internal/wire/ the request and status documents that cross the gap
internal/seal/ sign-then-encrypt, for the relay
internal/logfile/ gap analysis
internal/mcp/ JSON-RPC over stdio, no dependencies
internal/estate/ which transport repo a name refers to
internal/plant/ what to send the operator
internal/site/ markdown subset, CSS, hero
site/content/ the documentation, one source, three renderings
infra/ terraform: DNS, Pages, R2 state
docs/specs/ the designs, written before the codeThe relay server is its own repository, dbhq-uk/heliograph-relay, because it holds no keys and must be publicly, obviously incapable of reading anything it carries.
MIT (c) 2026 DBHQ Consulting Ltd
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.
| Name | Required | Description | Default |
|---|---|---|---|
| estate | No | Which estate. Optional when only one is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It explicitly states the operation is non-mutating ('change nothing') and read-only ('read access is not write access'), and explains why discovering failure later is costly. It does not describe the exact output or any network side effects, but for a read-only check this is strong coverage.
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?
The description is two sentences with the main action and constraint front-loaded: 'Check whether the transport works from here, and change nothing.' The rationale in the second sentence earns its place by explaining when and why to run the tool.
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?
For a simple tool with one optional parameter and no output schema, the description adequately covers purpose, safety, and timing. The main gap is that the exact return value or result format is not described, but 'check whether it works' makes the outcome reasonably inferable.
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?
The input schema fully documents the single optional 'estate' parameter, so schema coverage is 100%. The description adds no parameter-specific meaning beyond the schema, placing it at the baseline score of 3.
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?
The description states a specific verb and resource: 'Check whether the transport works from here,' and adds a clear non-mutating constraint: 'change nothing.' This makes the tool readable as a connectivity diagnostic and distinguishes it from send-type tools, though it does not explicitly contrast with siblings like heliograph_status.
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?
The description gives an explicit trigger condition: 'Run this before a long step.' It also conveys an important exclusion: this is read access, not write access, so it should not be used as a substitute for a mutation. It does not name alternative tools, but the guidance is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the configured estates and the transport each uses. Call this first when you do not know which estate to act on.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'List' strongly implies a read-only operation, and the description states what information is returned: estates and their transports. However, with no annotations provided, the description does not explicitly disclose side-effect-free behavior, error conditions, or dependencies, leaving some behavioral transparency burden unmet.
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?
The description is two sentences with no filler. It front-loads the action and resource, then immediately adds the most important usage guidance. Every sentence earns its place.
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?
For a parameterless list tool without an output schema, the description covers what the tool does, what it returns at a high level, and when to call it. It could be more explicit about the exact output shape or failure behavior, but the core contextual needs for invoking this tool are met.
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?
The input schema has zero parameters and 100% schema description coverage, so there is no parameter meaning for the description to add. The baseline of 4 applies because the tool has no parameters and the description does not need to compensate for schema gaps.
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?
The description uses a specific verb ('List') and names a distinct resource ('configured estates') plus the additional detail of transport each uses. The phrase 'Call this first when you do not know which estate to act on' further distinguishes it from the sibling tools, making the purpose unambiguous.
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?
The description gives explicit guidance on when to use the tool: 'Call this first when you do not know which estate to act on.' It does not name specific sibling alternatives or exclusion conditions, so it falls short of a 5, but it provides clear and actionable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Log filename. Omit for the most recent. | |
| estate | No | Which estate. Optional when only one is configured. | |
| min_seconds | No | Shortest interval worth reporting. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It reveals key behavior: returns intervals sorted longest first, attributes each gap to the line before it, and reports an error when timestamps are all identical. It also explains the diagnostic rationale. It stops short of explicitly stating read-only semantics or exact output shape, but covers the most important behavioral traits.
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?
Four sentences, each carrying distinct value: concise purpose statement, return behavior, usage timing with rationale, and edge-case failure mode. No filler or repetition. The most decision-relevant information is front-loaded.
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?
Given no output schema and no annotations, the description covers the essential contract: what is returned, ordering, attribution, and error condition. It does not specify the exact structured return format, but for an analysis tool of this complexity the description is nearly complete. An agent can correctly decide when to call it and interpret its result.
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?
Schema coverage is 100%, so the 3 parameters (name, estate, min_seconds) are already fully documented in the schema. The description adds semantic context around the log/timestamp concept but does not meaningfully extend parameter understanding beyond the schema. Baseline 3 applies.
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?
The description opens with a precise verb+resource statement ('Where a run stalled. Returns the intervals in the log's timestamp column') and clearly distinguishes itself from log-reading by positioning itself as the pre-reading analysis: 'Do this before reading a long log.' This makes the tool's identity and scope immediately obvious and separate from siblings like heliograph_read_log.
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?
The description gives explicit when-to-use guidance: 'Do this before reading a long log: a hang and slow progress are indistinguishable without it.' It also explains when the tool cannot answer the question (buffered capture with identical timestamps). It does not explicitly name alternative tools or state when not to use it, but the timing guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| estate | No | Which estate. Optional when only one is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It meaningfully discloses the sort order ('newest first') and the naming convention linking log names to request ids returned by heliograph_send. It does not mention output shape or limitations, but the core behaviors needed for correct use are present.
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?
Two compact sentences carry the essential information: what the tool lists, ordering, the naming convention, and how to route to a sibling. Every sentence earns its place with no redundant filler.
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?
The description tells the agent what will be returned (log names), the ordering, and how names relate to prior send requests, while pointing to the read tool for content. Since there is no output schema, this is adequate for a simple listing tool, though a note about pagination or absence of logs would make it fully complete.
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?
Schema description coverage is 100%, so the single 'estate' parameter is already fully explained by the schema: 'Which estate. Optional when only one is configured.' The description adds no parameter-level meaning, but none is needed.
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?
The description states a specific verb and resource: 'List the captured logs, newest first.' It also clearly distinguishes this tool from its siblings by noting that it is for finding a log while heliograph_read_log is for reading one.
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?
The description provides explicit routing guidance: 'Use this to find a log; use heliograph_read_log to read one.' This tells the agent exactly when to select this tool versus its most relevant sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Log filename. Omit for the most recent. | |
| estate | No | Which estate. Optional when only one is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Read' signals a non-mutating operation, and the description explains the meaning of exit statuses. No annotations are present, so the description carries the behavioral burden; it does so reasonably well.
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?
The description is somewhat verbose and includes repeated emphasis ('Read all of it') and a metaphorical control comparison. It conveys useful context but could be tightened.
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?
No output schema is provided, so the description should clarify the return format. It mentions UTC timestamps and exit semantics, but does not specify the full output structure or error behavior.
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?
The schema already fully describes both parameters ('name' and 'estate') with clear defaults and optionality. The description adds no further parameter detail, so baseline is appropriate.
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?
The description clearly states the verb 'Read' and the resource 'captured log whole', making the primary purpose obvious. It does not explicitly differentiate from sibling tools like heliograph_logs, but the intent is still clear.
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?
Provides interpretive guidance about reading the whole log and the meaning of a green exit, but does not explicitly state when to prefer this tool over alternatives like heliograph_logs or heliograph_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | Environment for the run, for example {"HOSTS":"sql01 sql02"} | |
| note | No | Free text for the next human. The station ignores it. | |
| step | Yes | A step registered in the station's run.sh, or a path such as steps/net-probe.sh | |
| estate | No | Which estate. Optional when only one is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses several non-obvious behaviors: the call is fire-and-forget, the station has discretion whether to execute the step, mode-less steps are refused, and state-changing steps require CONFIRM=yes plus a station started with --allow-actions. The mong these (publish success vs execution success) is a genuinely important behavioral trait an agent would otherwise discover only after a failed run.
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?
Three sentences, zero filler. The core action is front-loaded, then the async consequence, then the execution conditions. Every sentence earns its place and the most decision-relevant constraints appear last without being buried.
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?
For a tool with no annotations and no output schema, the description is thorough: it explains the non-blocking contract, how to obtain the result (poll status, read log), and refusal conditions. The remaining gap is that it never states what the immediate response contains (e.g., a run identifier needed to correlate with heliograph_status), which an agent needs since no output schema exists.
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?
Schema coverage is 100%, so the baseline is 3; all four parameters (env, note, step, estate) are already documented. The description adds semantic value by explaining what the station does with the step parameter — refusal if no mode is declared, and extra authorization requirements for state-changing steps — which clarifies meaningfully how step and env interact.
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?
The first sentence names a specific verb and resource ('Publish a step for the station to run') plus the key behavioral trait (returns immediately). It explicitly differentiates from siblings by saying it does NOT wait and directing the reader to poll heliograph_status and read the log, which distinguishes it from at least two sibling tools without needing to open their schemas.
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?
The description gives an explicit post-call workflow: do not wait, poll heliograph_status until terminal, then read the log. It also states the conditions under which this tool is effective (step must declare a mode; state-changing steps need CONFIRM=yes and --allow-actions), so the agent knows when the call will have no effect. Vivid routing to named siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. refused is not a failure: it means the station would not run the step, and the reason names the flag that would permit it.
| Name | Required | Description | Default |
|---|---|---|---|
| estate | No | Which estate. Optional when only one is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it explains the state enum, the meaning of an empty state, and that 'refused' is not a failure and that the reason names the flag that would permit it. This adds material beyond the schema and prevents misinterpreting a failure-like state.
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?
Three sentences with no filler: the core purpose is front-loaded, and each sentence adds a distinct state or semantic clarification. It is easy to scan and every sentence earns its place.
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?
This is a low-complexity tool with one optional parameter fully documented and no output schema. The description conveys the result vocabulary (one of five states or empty) and explains ambiguous states. It does not describe the exact payload shape, but the state-based output is sufficiently implied.
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?
The single optional parameter 'estate' is fully documented in the schema, and the description adds no parameter-level detail. With 100% schema description coverage, score 3 is the appropriate baseline even though the description omits param specifics.
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?
Clearly describes a status/state retrieval for a station and enumerates the possible state values, so an agent knows what this tool reports. It does not use an explicit verb like 'get' and does not explicitly distinguish itself from siblings, but its resource and state vocabulary make the function evident.
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?
The description provides no guidance about when to call this tool rather than a sibling such as heliograph_logs or heliograph_send, and no preconditions or exclusions are given. Usage context must be inferred from the word 'status' and the sibling names.
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.
v0.1.0heliograph_doctorheliograph_estatesheliograph_gapsheliograph_logsheliograph_read_logheliograph_sendheliograph_statusEach 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.
Remote shell and detached long-running jobs on your own machines — no SSH, open ports or VPN.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Dead-man switch monitors for cron & AI agents with dependency-cascade alerts. No account needed.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dbhq-uk/heliograph'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
