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
} |
| extensions | {
"io.modelcontextprotocol/tasks": {}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bowire.discoverA | Run discovery against a server URL and return the discovered services and methods. Optional |
| bowire.lintA | Discover a server URL and run Bowire's design-time linter over the API surface — the same rules |
| bowire.contract.matrixA | Read the contract-verification results stored under .bowire/contract-results (written by |
| 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 } }. |
| 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.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.env.listA | List Bowire environments stored under ~/.bowire/environments.json — names, server URLs, variables. |
| 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.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.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.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.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.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.removeA | Delete a captured auth recording. Idempotent — reports whether a file was removed. Two-step by default (confirm=true or confirmationToken). |
| 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.har.importA | Convert a HAR 1.2 trace into a Bowire recording. Reads the HAR file at |
| bowire.importA | Import an Insomnia export (v4 JSON/YAML or v5 YAML), a Bruno collection (a directory of .bru files or OpenCollection YAML, or a bundled OpenCollection file) or .http files (one file, or a directory of them with http-client.env.json) into Bowire collections and environments (#674). Returns { format, collections, environments, report } where report lists what was approximated or skipped and which credentials sit in clear text. With |
| bowire.export.httpA | Write Bowire collections as a .http file the IDEs run (Rider, IntelliJ, Visual Studio 2022, VS Code REST Client) plus http-client.env.json (#673). Reads a .bww workspace file, a workspace's collections.json or an array of collections. Secrets are never written: {{secret.x}} references become names to fill into http-client.private.env.json. Returns { http, envJson, report }. |
| 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.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.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.mock.stopA | Stop a mock server previously started by bowire.mock.start. Idempotent — returns false if the handle is unknown or already stopped. |
| bowire.mock.listA | List currently running mock servers spawned via bowire.mock.start. Includes handle, port, and a connect URL per mock. |
| 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.record.stopA | Stop the active server-side recording (#285) and flush the buffer into ~/.bowire/recordings.json. Returns { stopped, recordingId, stepCount }. When that file is not a {"recordings":[…]} store the call is refused and the session stays open. 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.record.replayA | Switch the active server-side recording session into replay mode for the given recording id (#285); a session that belongs to another recording is left alone and the call is refused. 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.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.test.runA | Run a Bowire test collection or flow, as |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| 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. |
| 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. |
| scan-service | Run the Bowire security scanner against a URL and summarise SARIF findings. Operator workflow: scan → triage top severities → propose fixes. |
| 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. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
TDQS
Scored across 28 tools
Most tools map to clearly distinct resources/actions (invoke vs subscribe, mock.start/stop/list, record.start/stop/replay/list). A few boundaries blur: bowire.discover vs bowire.lint (lint also discovers), bowire.test.run vs bowire.assert, and bowire.import vs bowire.har.import both parse external formats. Descriptions disambiguate these well, but note record.list's text calls record.replay '(planned)' even though it exists, which could confuse an agent.
Consistent dotted namespacing (bowire.<resource>.<verb>, e.g. mock.start, auth-recording.list, cookies.clear) throughout. A handful of domain-level verbs sit at the top level (invoke, subscribe, assert, discover, lint, import), which is a reasonable but slightly different convention. Easily readable and predictable overall.
28 tools is on the heavy side; even for a full API-testing platform some are niche diagnostics (contract.matrix, report.rollup, network.get, allowlist.show) that broaden the surface considerably. Each maps to a real capability from the underlying CLI, so it's not bloat for bloat's sake, but the set is at the upper end of comfortably navigable.
Strong lifecycle coverage: discover/invoke/subscribe, mock start/stop/list, record start/stop/replay/list, import/export, assertions, test runs, contract matrix, lint, auth recordings, cookies, allowlist. Gaps remain around mutating stored artifacts — no delete/rename for recordings, no collection/workspace CRUD or env mutation, and no way to inspect or edit assertions or collections after creation. Agents can work around most of these but will hit dead ends for cleanup/management tasks.