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
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
open_targetB

Open a target and record intake (declared purpose, jurisdiction, ToS snapshot). target: cli:docker: | cli:build: | cli:local | web: | android:: | desktop:docker:. strict: every release needs a person's approval at a terminal. target_options (web): reset_command, reset_check_url, contract_selectors {source, selectors}, api_templates, profile {asset_hosts, ...}; see the observer guide.

set_mapperC

Replace the mapper rules (drop/mask/rename/classify). Creates a new mapper version.

run_sequenceB

Reset the target, apply the inputs, and return raw observations and symbols. symbols_only drops the raw observations; keys (e.g. ["path", "status", "alerts"]) keeps only those parts of each symbol.

define_actionsB

Define named actions (CLI invocations: argv, stdin, files, env, stdin_mode, stdout_mode, timeout_s) for learning flows of stateful CLIs.

discover_cliB

Discover a CLI's interface: help structure confirmed by behavior probes. Help prose is kept as dirty-side evidence only; the result is structure (options, arity, value types).

probe_cliC

Probe a CLI feature: one-factor sweep, pairwise over accepted classes, noise calibration (rerun + env variations), probe table, mined decision-table claims and unknowns. hints = {cmd, base, selector_options, takes_files, default_input, sweep_inputs, inputs, pair_inputs, operand_type, unicode_argv, skip_options, extra_inputs, extra_values}.

probe_web_fieldB

Probe one form field (web, Android or desktop UI): equivalence classes for its kind (text/email/password/number or custom classes), a length-boundary search, per-class outcomes and folded claims. prefix = named actions that reach the form; submit = the named action that submits it. Boundary classes become named actions you can add to learn_flow's alphabet. When accepted values change the outcome (computed results), say what acceptance looks like: accepted_if = {subset: {...}} and/or {text_contains: '...'}. Number fields skip the length search (their limits are ranges). Without submit, the outcome is read right after typing (live previews, totals, counters).

check_rulesC

Check observer-authored rules against the original. Each rule: {statement (your own words), origin: documented|inferred-intent|observed, kind, checks: [{kind: outcome|same|differs, a: invocation, b: invocation (same/differs), expect: subset (outcome), keys: [..] (optional)}]}. Falsified documented rules are reported as documentation/behavior conflicts.

coverageC

Coverage of a feature inventory {item: [patterns]} by probes and rule checks (options are added automatically). Uncovered items become unknowns.

ingest_docsB

Register public documentation you read (dirty side). Its paragraphs join the gate corpus so copied wording is flagged; write rules in your own words.

learn_flowC

Learn a state machine for a feature with KV or L# under an explicit oracle budget.

propose_claimC

State a falsifiable claim as a trace check (expect: symbol per step, null = any).

falsify_claimC

Try to falsify a claim with fresh, uncached probes.

list_claimsC

List claims, optionally for one feature.

list_rulesB

List the rules recorded for a feature: id, statement, status, failed checks.

list_feature_unknownsB

List unknowns (yours and the ones coverage generated) with id, question and status, so they can be answered with update_unknown.

record_unknownC

Record something that could not be observed (missing coverage is unknown, not absence).

discover_uiA

UI targets: crawl from the start screen (or after the named start actions, e.g. a sign-in) clicking every enabled control; screens are identified by route, headings and controls. Defines a click[role:name] action for every control found and records the inventory that coverage and suggest_probes use. Start here, then probe fields and state rules.

suggest_probesB

Concrete next steps for the feature's coverage gaps: fault actions with a path that makes the call, probe_web_field arguments for unprobed fields, click paths for unexercised controls. Run after discover_ui and after each batch of rules.

retract_ruleB

Retract one of your rules (e.g. superseded by a reworded version), with a reason. Rule ids are in check_rules results.

update_unknownB

Mark an unknown resolved / out-of-scope / investigating (or reopen it) with a note. Resolved unknowns leave the release; the audit log keeps the history.

blocked_hostsB

Web: third-party hosts the app tried to load during one episode (reset + actions); candidates for target_options.profile.asset_hosts when layout depends on them.

api_contractB

Web: the value-free backend contract observed so far (paths, methods, statuses, body shapes). Fold data-bearing path segments with target_options.api_templates.

compile_specC

Compile a spec draft (model + claims + unknowns) for a feature.

review_specB

Run the gate on a draft without releasing it: findings grouped by class (expected-output / interface / prose), which are approved, and prose findings in full.

release_specA

Release a draft through the gate. Strict mode: succeeds only once a person has approved every finding and acknowledged coverage gaps (teardown approve); rewrite prose findings instead of waiting for approval. Standard mode: refused while measured coverage items are neither exercised nor explained, unless accept_gaps gives the reason they ship as unknowns.

add_quoteC

Standard mode only: allow one literal through the gate, with the reason it is functionally necessary.

approve_observed_outputB

Standard mode only: approve byte-exact output the behavior requires (default: help/usage/version output) as functional quotes. Records who approved it.

list_ticketsC

List questions from the clean side.

answer_ticketC

Answer a clean-side question; the answer is gate-checked.

audit_verifyB

Verify the audit log's hash chain.

Prompts

Interactive templates invoked by user choice

NameDescription
observe_targetThe observer playbook: discover, probe, inject faults, state rules, close coverage gaps, release.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.8/5.0

Scored across 31 tools

Disambiguation3/5

Most tools map to distinct workflow stages such as open_target, discover_ui, probe_web_field, and release_spec, but rule/claim checking and the multiple list_* introspection tools overlap conceptually. An agent may struggle to choose between check_rules/propose_claim/falsify_claim or list_rules/list_claims, and the large surface increases misselection risk.

Naming Consistency4/5

Names are predominantly verb_noun (retract_rule, probe_cli, review_spec), with only coverage, blocked_hosts, and api_contract as noun-only exceptions. The probe_web_field versus probe_cli split is a minor inconsistency but overall the naming is predictable.

Tool Count2/5

31 tools exceeds the 25-tool threshold and includes several narrow introspection/listing tools such as list_claims, list_rules, list_feature_unknowns, list_tickets, blocked_hosts, and api_contract that could be consolidated. The multi-target workflow explains some breadth, but the surface is heavy for an agent to manage.

Completeness4/5

The surface covers target intake, UI/CLI discovery, field/CLI probing, sequences, flows, rules/claims, coverage, unknowns, docs, spec compile/review/release, tickets, audit, and mapping. Minor gaps exist around session/target listing or closing and claim lifecycle cleanup, but the core teardown-to-release workflow is well supported.

Maintenance

ActivityMaintained
ResponsivenessNo issues