Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
find_page_readsA

Opens a page in headless Chromium and lists the JSON GET requests it makes while it loads. Use it to choose the endpoint for check_read_recovery. Only successful page fetch and XHR reads are seen; native, IPC and service-worker traffic is not.

check_read_recoveryA

Loads the page healthy, then fails one GET endpoint with each fault kind and checks that the ready marker comes back: by itself (recovery "automatic") or after clicking retrySelector ("retry"). Returns an outcome per fault, why the healthy baseline failed if it did, the text the screen showed under a fault it did not recover from, and the report folder, which includes fix-brief.md and reproduce.mjs.

start_network_faultsA

Starts a loopback HTTPS proxy for an app's own connections (an SDK, a main process, a CLI or a test run). Start the app or tests with the returned environment; connections pass until set_network_faults arms rules. Faults apply to whole connections per host: HTTPS stays end to end.

set_network_faultsA

Replaces the armed rules, or removes them all with restore: true. Windows count from this call. Set dropOpen on a rule so clients that keep connections open have to reconnect.

network_fault_summaryA

Reports how many connections went through the proxy and, for the armed rules, how many each matched and faulted. A rule that faulted nothing means the app did not use the proxy or the host name is wrong.

stop_network_faultsA

Removes every fault, closes the proxy and returns its final summary.

find_suspectsA

Reads JavaScript and TypeScript sources, without running them, for two patterns: UNKNOWN_AS_EMPTY (a failed or unexpected read becomes an empty collection, so "unknown" looks like "none") and FAILURE_ONLY_LOGGED (a read stores its data when it succeeds, but its failure is only logged). Each suspect names the read to fail and the check that proves or dismisses it. Use changedSince "main" to scan only what a branch changed. Needs TypeScript in the project.

compare_reportsA

Compares reports of the same check from before and after a change, such as main and a branch, and returns a verdict (IMPROVED, PARTLY_IMPROVED, REGRESSED, MIXED, UNCHANGED, INCONCLUSIVE or NOT_COMPARABLE), what happened to each problem, and a Markdown block for a pull request. A problem counts as gone only when a complete run after the change checked it, so a run that stopped early is never a fix. Give several reports per side for repeated runs.

verify_changeA

Call with baseline true before changing the code, and without it before saying the change is done. The plan file lists the checks that prove the change. Verify reruns them, compares the runs with the baseline, and scans the lines changed since the plan base for suspects. VERIFIED needs every check improved or clean with complete runs on both sides, and no suspect on a changed line; otherwise the reasons say what to resolve. Do not call a change done while it is NOT_VERIFIED.

run_recovery_probeA

Runs a Recovery Probe command that has no dedicated tool, such as check and discover for an Electron app or an attached browser, action, observe (with --steps, --network or --files), refresh, reads, windows, android --list or doctor (setup checks), and returns its exit code and output. Commands: check, discover, action, reads, windows, observe, refresh, android, doctor. Pass --json where the command supports it. See the package docs for each command's configuration.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 10 tools

Disambiguation4/5

Most tools target clearly distinct steps in the recovery-testing workflow, and the start/set/stop network-fault trio is especially clear. There is some overlap between check_read_recovery and run_recovery_probe (which can run a generic check), and between compare_reports and verify_change, though the descriptions mostly disambiguate them.

Naming Consistency4/5

Almost all tools use a predictable snake_case verb_noun pattern, and the fault lifecycle tools are consistently named. The main deviation is network_fault_summary, which is noun-first rather than verb-led, but the set remains readable.

Tool Count5/5

Ten tools is well-scoped for a recovery probing server covering fault injection, endpoint discovery, recovery checks, static suspect scanning, report comparison, verification, and a generic command runner. Each tool appears to earn its place without an excessive surface.

Completeness4/5

The network-fault lifecycle, recovery check, suspect discovery, report comparison, and change verification workflows are well covered. Minor gaps remain around directly creating or managing the plan file used by verify_change and listing or cleaning up reports, though the generic run_recovery_probe tool helps cover other commands.

Maintenance

ActivityActive
ResponsivenessUnresponsive