Bowire MCP
OfficialServer 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": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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.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.contract.matrixA | Read the contract-verification results stored under .bowire/contract-results (written by |
| bowire.discoverA | Run discovery against a server URL and return the discovered services and methods. Optional |
| 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 |
| 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.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
| Name | Description |
|---|---|
| mock-from-recording | Spin 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-service | Run the Bowire security scanner against a URL and summarise SARIF findings. Operator workflow: scan → triage top severities → propose fixes. |
| fuzz-method | Run Bowire's fuzz scan against one method and summarise findings. Maps to the existing `bowire fuzz` CLI flow via the bowire.invoke tool. |
| replay-recording | Replay 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-responses | Diff 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
| Name | Description |
|---|---|
| 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. |
| Environments | All 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 plugins | Sibling 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
Scored across 25 tools
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.
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.
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.
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.