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": true
}
logging
{}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
bowire.allowlist.permitA

Record that a URL is now allowed for bowire.invoke / bowire.subscribe — appends to ~/.bowire/typed-urls.json (the same file --allow-invoke seeds from) and adds the URL to the in-memory allowlist for the rest of this session. Use to surface "the user just typed this URL into the workbench" without re-reading the file. Returns whether the URL was new + the resulting list size.

bowire.auth-recording.removeA

Delete a captured auth recording. Idempotent — reports whether a file was removed. Two-step by default (confirm=true or confirmationToken).

bowire.auth-recording.listA

List captured auth recordings (credential-free) that a mock's auth requirement can resolve by id. Returns { workspace, recordings: [{ id, name, scheme, capturedAt }] }. The credential value is never returned.

bowire.record.replayA

Switch the active server-side recording session into replay mode for the given recording id (#285). When no session is open, opens a fresh one bound to the supplied recording id so the workbench can drive replay. Returns the resulting session state. Two-step by default; pass confirm=true to skip the confirmation gate.

bowire.cookies.clearA

Clear a cookie jar (#681): an environment's whole jar, or one domain in it. Two-step by default: the first call returns { pending, confirmationToken, plan }; re-invoke with confirm=true or pass the token back.

bowire.env.listA

List Bowire environments stored under ~/.bowire/environments.json — names, server URLs, variables.

bowire.assertA

Append a test assertion onto a step inside an on-disk recording. Targets either ~/.bowire/recordings.json (when recordingId is set) or the supplied recordingPath. The assertion shape matches the Newman-style probe Bowire runs after replay: { path, op, expected }. Supported ops: eq, ne, gt, gte, lt, lte, contains, matches, exists, notexists, type. Use path="status" to assert on the HTTP/gRPC status name; otherwise path is a JSONPath rooted at the response body. Returns the assertion id + the step it was attached to.

bowire.record.listA

List Bowire recordings stored under ~/.bowire/recordings.json — id, name, step count, captured at. Step bodies omitted; ask for details via the (planned) record.replay tool.

bowire.auth-recording.capture-flowA

Run an auth flow (a scriptable login → token chain) and store the captured token as a named auth recording. Bowire EXECUTES the flow — an outbound HTTP call — so this is two-step by default (confirm=true / confirmationToken). Secrets in the flow are read from {{env.NAME}}, never inlined. Requires a host with flow-capture enabled; returns an error otherwise. Parity with bowire auth-recording capture --flow and the workbench's flow-capture.

bowire.subscribeA

Subscribe to a streaming method (server-streaming, SSE, MQTT topic, websocket) and return collected frames after the sample window elapses. Frames are returned as raw strings; the agent decodes them in follow-up reasoning.

bowire.record.stopA

Stop the active server-side recording (#285) and flush the buffer into ~/.bowire/recordings.json. Returns { stopped, recordingId, stepCount }. Idempotent — returns { stopped: false, reason: "no-active-session" } when no session is open. Two-step by default; pass confirm=true to skip the confirmation gate.

bowire.auth-recording.captureA

Store a credential as a named auth recording so a mock's auth requirement can resolve it by id — parity with bowire auth-recording capture and the workbench picker. Two-step by default: the first call returns { pending, confirmationToken, plan }; re-invoke with confirm=true or the token to store it. The credential is written to the local store only and is never echoed back.

bowire.contract.matrixA

Read the contract-verification results stored under .bowire/contract-results (written by bowire contract verify) and roll them up into the same consumer x provider matrix the workbench Contracts rail and bowire contract matrix render. Purely local: it reports stored verdicts and never calls a provider itself. Returns { consumers: [...], providers: [...], cells: [{ consumer, provider, status: pass|fail|notRun, lastRun, passedInteractions, totalInteractions, failures: [{ description, method, error }] }], summary: { passed, failed } }.

bowire.discoverA

Run discovery against a server URL and return the discovered services and methods. Optional protocol filters to one plugin (grpc, rest, graphql, signalr, mqtt, ws, sse, mcp, odata, socketio); without it every registered protocol that handles the URL gets a turn. The attempts array reports what each plugin did — outcome is ok / empty / partial / error / timeout — so an empty services list always comes with an explanation instead of leaving you to guess. partial means that plugin returned services AND hit a fault while producing them, so its contribution is incomplete; the optional details array breaks the message down step by step.

bowire.allowlist.showA

Diagnostic: show the URLs the agent is currently allowed to call via bowire.invoke / bowire.subscribe, plus the toggles that fed the list (environments seed, typed-URLs seed, --allow-arbitrary-urls).

bowire.record.startA

Begin a new server-side recording (#285). Subsequent capture-mode invocations on the same workspace land in the buffer until bowire.record.stop. Two-step by default: the first call returns { pending, confirmationToken, plan }; re-invoke with confirm=true or pass the token back. Mode: capture (default, record live invokes), proxy (record proxied flows), replay (drive replay from a pre-existing recording). One active session per process — start fails with a 409-equivalent message when a session is already open.

bowire.mock.listA

List currently running mock servers spawned via bowire.mock.start. Includes handle, port, and a connect URL per mock.

bowire.mock.stopA

Stop a mock server previously started by bowire.mock.start. Idempotent — returns false if the handle is unknown or already stopped.

bowire.cookies.listB

List the cookie jars (#681): per environment, the cookies Bowire's calls send and keep — domain, path, name, expiry, Secure / HttpOnly / SameSite. Values are credentials and are masked.

bowire.har.importA

Convert a HAR 1.2 trace into a Bowire recording. Reads the HAR file at harPath, optionally writes the recording JSON to outPath (use "-" or omit to return the JSON inline), and returns a summary { recordingId, stepCount, authHeaders, redacted, outPath?, recording? }. Set redactSecrets to strip credential headers (Authorization, Cookie, X-Api-Key, …) before import. Pair with bowire.mock.start { recording: } to serve the trace back.

bowire.network.getA

Show how Bowire's outbound connections leave the machine (#680): proxy mode and URL, bypass list, CA bundle, which layer set each value, what is misconfigured, and which protocol plugins can use the proxy. Passwords are shown only as their reference, never the value.

bowire.invokeA

Invoke a unary method discovered via bowire.discover. body is a JSON string; metadata is a flat object of header / gRPC metadata key-value pairs.

bowire.lintA

Discover a server URL and run Bowire's design-time linter over the API surface — the same rules bowire lint and the workbench Lint rail use. Flags design smells (secrets or PII in responses, unbounded list responses, missing versioning, string-typed timestamps, ...) each with a severity, honouring the workspace's .bowire/rules.json. Returns { findings: [{ ruleId, severity, service, method, field, message }], summary: { total, high, medium, low, info } }.

bowire.mock.startA

Spin up a local Bowire mock server that replays a recording (or synthesises responses from a schema). Returns a handle the agent uses with bowire.mock.stop. Multiple mocks can run concurrently on different ports. Two-step by default (controlled by RequireConfirmationForMutations): the first call returns { pending: true, confirmationToken, plan }; re-invoke with confirm=true or pass the token back as confirmationToken to actually start the mock.

bowire.report.rollupA

Roll the reports Bowire writes up into one view across services — the portfolio question. Reads lint findings, contract-verification results, benchmark run histories, k6 summaries, scan SARIF and test JUnit from the given paths (directories are walked recursively) and returns one row per service. Purely local: it reads files that already exist and never calls a service. Returns { services: [{ service, worst: high|medium|low|info|null, lint, contracts, tests, benchmark, scanErrors, lastReportAt, sources }], summary: { services, atHigh, clean, skipped } }.

Prompts

Interactive templates invoked by user choice

NameDescription
mock-from-recordingSpin up a Bowire mock server from a recording and walk the user through verifying it. Maps to bowire.mock.start + a follow-up bowire.invoke.
scan-serviceRun the Bowire security scanner against a URL and summarise SARIF findings. Operator workflow: scan → triage top severities → propose fixes.
fuzz-methodRun Bowire's fuzz scan against one method and summarise findings. Maps to the existing `bowire fuzz` CLI flow via the bowire.invoke tool.
replay-recordingReplay a captured recording against its original target and report whether every response still matches. Useful as a smoke-check after a deploy or schema change.
compare-responsesDiff two recordings step-by-step — useful for catching regressions or drift between staging and prod captures.

Resources

Contextual data attached and managed by the client

NameDescription
Workspaces (index)Every workspace this identity has — id, name, and whether it is backed by a git checkout. Use an id here with bowire://workspaces/{workspaceId}/collections, /recordings or /flows to read what the workbench actually shows. An empty list means the host never adopted workspaces, in which case the plain bowire://collections, ://recordings and ://flows are the right ones.
Collections (index)Index of saved request collections (Postman-style). Each entry's items: protocol, service, method, body, env-vars. On a host that uses workspaces this file is the pre-workspace one and is usually empty or stale — read bowire://workspaces first and use the workspace-scoped resource instead.
EnvironmentsAll Bowire environments stored in ~/.bowire/environments.json — names, server URLs, variables, auth blocks. Read this to pick the active env before invoking; use the bowire.env.list tool for the same data via the tools/call path.
Installed pluginsSibling plugins in the host's plugin directory — package id + version per directory. That is ~/.bowire/plugins/ by default, or wherever the host was pointed with --plugin-dir / BOWIRE_PLUGIN_DIR / Bowire:PluginDir. Bundled plugins (the ones shipped inside the Bowire tool) are not listed here; the tool's --version banner covers them.
Recordings (index)Index of every captured recording — id, name, protocol, captured-at timestamp, step count. Step bodies omitted to keep the index cheap; read bowire://recordings/{id} for the full content.
Flows (index)Index of every saved visual flow — name, step count, last-modified. On a host that uses workspaces this file is the pre-workspace one and is usually empty or stale — read bowire://workspaces first and use the workspace-scoped resource instead.

TDQS

A3.7/5.0

Scored across 25 tools

Disambiguation4/5

Tools are largely organized around distinct resources (recordings, mocks, auth recordings, cookies, allowlist, env), so most boundaries are clear. There is mild overlap between bowire.record.replay and bowire.record.start (which has a replay mode), and between bowire.auth-recording.capture vs capture-flow, but descriptions disambiguate them adequately.

Naming Consistency4/5

Names follow a predictable dotted namespace pattern (bowire.<domain>.<action>), e.g. record.start, mock.stop, cookies.clear. Minor deviations exist: several top-level actions (discover, invoke, subscribe, assert, lint) skip the domain level, and auth-recording uses a hyphen while other multi-word segments do not.

Tool Count3/5

At 25 tools the set sits at the heavy edge of the acceptable range, but the domain genuinely spans discovery/invoke, recording, mocks, auth capture, cookies, allowlist, network, HAR, lint, and reporting. Each cluster is small, yet the aggregate is borderline crowded for a single server.

Completeness4/5

Coverage is broad: recordings (start/stop/replay/list/assert), mocks (start/stop/list), auth capture, cookies, allowlist, discovery, invoke, lint, and reporting are all present. Minor gaps remain—no delete/export for recordings, no allowlist revoke, no detailed mock or recording get—that agents can mostly work around.