teardown-observe
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| probe_web_fieldB | Probe one form field (web, Android or desktop UI): equivalence classes for its kind (text/email/password/number or custom |
| 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 |
| 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 ( |
| 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
| Name | Description |
|---|---|
| observe_target | The observer playbook: discover, probe, inject faults, state rules, close coverage gaps, release. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 31 tools
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.
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.
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.
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.