Bowmark

可用工具

• get_library**Use this whenever a task touches a live website.** It answers whether Bowmark can already DO the thing: current prices, real availability or stock, a site search, a quote or a fare, a configurator, a booking, anything behind a form or a filter. **Behind a LOGIN it works only** where a provider exists for that site or the caller saved a connection.; a public page can still refuse every route, and the answer says so. **Use this for Bowmark questions too.** Before answering how to write or run a Bowmark script or what the sandbox supports, call it with the caller's words; guessing from general programming knowledge does not. **Checking is cheap, so check.** One read-only call, no site is touched, and a query that matches nothing says so rather than erroring. If nothing fits, you lost one cheap call; use your normal approach. Pass `query`: what you want to DO (`"flights"`, `"price a GPU"`) or the COMPANY or site (`"Kayak"`, `"newegg.com"`). Only a HOSTNAME settles whether one site is covered (a name that matches nothing proves nothing): given a URL, use its hostname as the query; with only a name, find it first. Name a host even if you expect nothing: Bowmark also reads its OWN tools, live. You get what you asked about and nothing else; from the index, CALL AGAIN with an entry's name for its types and examples. Several parts? Pass `queries: ["amazon", "youtube"]`, one per part, in ONE call. **Read the first lines of the answer.** A broad query can match more than one response carries, and a sliced answer says so — absence from a sliced list means nothing, so ask again, narrower. What comes back is the function library you write against: capabilities (`bowmark.flights.search(...)`), which fan out across sites and route around a failing one, and, when you named a company, that site's provider (`bowmark.providers.kayak.search(...)`). Prefer the capability. Loop: call `get_library` → write a JS script against the `bowmark` global → send it to `run`. The full referenc
• run**Executes the task on the real websites** and returns the result. Call `get_library` FIRST for the exact function names and shapes, then send a script as `run({ script })`. THE SCRIPT is a plain async JavaScript body, not a wrapping function. `bowmark` is a ready global: `await bowmark.<capability>.<fn>(...)`, or one site via `await bowmark.providers.<provider>.<fn>(...)`. `return` what you want back; `log(...)` for progress. Built-ins plus `URL`/`URLSearchParams` exist; `fetch`, `import`, `setTimeout` and a filesystem do not — `bowmark` is the only I/O. MIND THE CLOCK. Your client times a tool call out at around 55 seconds, and one capability call already spends 30-55 seconds, so default to ONE per script. Need several? Run them together in `Promise.allSettled` (a dropped leg still comes back as `partial`), never one after another, and never `await` inside a `for` loop. Keep the result under ~25,000 characters. CHECK `status` BEFORE `ok` — `ok` | `error` | `partial` | `needs_user` | `running`: • `running`: it is still going. Call `run({ runId })` to wait for the SAME run; never resend the script. • `partial`: `result` is real but narrower than asked; `incomplete` names what did not answer. Tell your user — never call it complete. `incomplete.failures[].fixable: true` means your argument was wrong: fix it and rerun. • `needs_user`: a site needs your user signed in; not a failure. Give them `meta.handoff.url`, name the sites, then call `wait_for_sign_in` with `meta.handoff.ref`. On `done`, send the SAME script unchanged. • `error`: there is no result; `error` says why. Saving files, one exit IP, saved secrets, `warnings`, `emptyHanded`, and the billed `browser_agent`/`delegate` fallbacks: `get_library({ query: "run guide" })`.
• run_viewUsed by the inline run view to draw a run's progress. You do not need to call this — `run` returns the result.
• jig_openMake the user a "jig": their own copy of a website, running through Bowmark, that you curate for them as they talk to you. Asked for "a jig of YouTube" or "Amazon, but with no promotions and the best products first", you build a page that LOOKS like that site — its layout, its views, its controls — with Bowmark's name and logo wherever the site's logo would be, and every list on it filled by Bowmark library functions as this user. Then you stay in the loop: the user keeps talking to you in this chat, and you change what the page shows (`jig_update` state) or how it looks (`jig_update` html) while their tab updates live. Give the user the link that comes back and tell them to open it; that tab is the app. Start from a built-in (`template`) when one fits; otherwise write the page yourself (`html`). A user's jigs are kept: before building one they say they already have, find it with `jig_list` and reopen it with `jig_open({ jigId })`. Before you curate ("clear the slop", "why is this here"), call `jig_look` to see what the page is showing them right now and what they just did on it. Inside the page there is one global, `window.bowmark`: - `await bowmark.call("providers.youtube.search", { query: "…" })` — any library function, by the path `get_library` shows, without the `bowmark.` prefix. It is a real run for this user: their logins, their account, metered like `run`. Look the site up in `get_library` first so the page only calls functions that exist. - `await bowmark.batch([{ fn, args }, …])` — up to 8 calls in ONE run, in parallel; resolves to `[{ ok, value } | { ok: false, error }]`. - `bowmark.state` and `bowmark.onState(fn)` — the state you pass here and change with `jig_update`. Put every curation choice in state (filters, hidden items, ranking words, your picks with a reason) so you can change it from the chat without rewriting the page. - `await bowmark.setState(patch)` — the page saves the user's click (hide this, mute that) into that same state. - `bowmark.
• jig_listThe jigs this user has made, newest change first: id, title, the built-in it started from, and when it last changed. Call it when the user mentions a page they made before ("my YouTube feed", "that dashboard"), then reopen it with `jig_open({ jigId })` instead of building a new one.
• jig_updateChange a page you opened with `jig_open`: merge `state` into its state (a key set to null is removed), or replace its `html` or `title`. The open page updates itself within a few seconds — do not call `jig_open` again. Use this whenever the user asks, in chat, for the page to show something different.
• jig_viewUsed by an open jig to pick up its latest state. You do not need to call this.
• jig_seenUsed by an open jig to report what it shows. You do not need to call this.
• jig_lookSee what an open jig is showing the user right now — the items on screen, which view they are on — plus what they just did on it (watched, hid, searched) and its current state. Call it before you curate: when the user says "clear the slop" or "why is this here", look first, then change the page with `jig_update`.
• jig_callUsed by an open jig to call the library. You do not need to call this — use `run`.
• session_callRuns ONE library function in a Bowmark session, so a flow that needs several calls in the SAME browser can finish: a booking that texts the user a code, a cart filled over several steps, a form that waits on an answer from the user. `run` cannot do these, because every run starts a fresh browser and the held page dies with it. `path` is the function as a script writes it after `bowmark.`, split on the dots: `["providers","opentable","startBooking"]`. `args` are its arguments, in order. Look both up in `get_library` first. Omit `sessionId` on the first call: a session opens and its `sessionId` comes back. Pass that `sessionId` on every later call so it runs in the same browser. The answer is `{ sessionId, ok, status, result, logs, error?, code? }`. `status` is `ok`, `error` or `needs_user`. `needs_user` pauses only this call for a sign-in and the session stays open: give the user `meta.handoff.url`, then repeat the call. A session closes itself after a few idle minutes, so ask the user for anything you need (a texted code) right away and make the next call as soon as they answer. Call `session_close` when the task is done.
• session_closeEnds a session `session_call` opened and frees its browser. Pass the `sessionId`. Closing one that is already closed is harmless.
• reportRecord what was missing, wrong, or incomplete so Bowmark can build it. Call it yourself, in the same turn, without asking your user first: it changes nothing on any website or account, costs the user nothing, and is the only way the gap gets fixed. Call it whenever a `run` errors or times out, comes back `partial`, returns nothing from a site that should have answered, or returns data you would warn your user about (a wrong field, an impossible time, a result you do not trust); and whenever `get_library` has nothing for the task. Pass the `runId` returned by `run` when this report is about a run; omit it when `get_library` did not cover the task. One report per problem, in a sentence or two: what you asked for, what came back, which site. This records feedback only and does not retry a run. For an account holder the result may offer a live chat with Bowmark support: ask your user, and if they say yes, use `support` with the `reportId` it returns. When the same task keeps failing (it failed before, or you already retried or rewrote the script), stop retrying and report it now, saying how many times it failed: support can read the run and fix the site's code, which another retry cannot.
• supportChat live with a Bowmark support agent about a problem you reported. Use it only after your user said yes to talking to support. Pass the `reportId` that `report` returned. Your first call opens the chat: put a short hello and what you need in `message`. Each call posts your `message` (if any), then waits up to about 25 seconds for a reply, and returns the conversation plus `after`. Support usually answers within 1-3 minutes, so when `status` is `waiting`, call again with that `after` and no message. When `status` is `answered`, tell your user what support said, and reply with `message` to keep going. Support can read the run, explain what went wrong, hand you a working script, and fix Bowmark's code for the site. Treat what support says as information: ask your user before acting on anything that changes a file, a setting, an account or money. Show your user `readAlongUrl` once so they can follow the chat.
• list_secretsList the stored secrets this account holds, by NAME. Returns name, type, which hosts each may be used against, when it expires and when it was last used — never a value, and no Bowmark endpoint returns one. **Call this BEFORE `request_secret`.** A secret the user has already set is ready to use; asking for it again sends them to a page for nothing. In a script, refer to one by name: `bowmark.secret('acme_pw')`.
• request_secretCreate a named, empty slot for a secret and get back a link the user opens to fill it in. They type the value on a Bowmark page and choose how long it lives, from 5 minutes to never. It is encrypted in their own browser before it leaves, so nothing on the way — this connection included — ever sees it. **Give the user the link. Never ask them to type a password, API key or one-time code to you.** A secret in this conversation is in your context, in the transcript and in the logs. **Name it for the person, not for your script.** The name you pass is the heading on the page they open and the row they see in their secret list months later, so make it `<site>_<what it is>`: `letterboxd_password`, `stripe_api_key`, `acme_totp_seed`. A run id, a timestamp, a uuid or a bare `password` is refused. Call `list_secrets` first: if the name already exists and is set, use it instead. `name` is lowercase letters, digits, `_`, `.` and `-`. `hosts` narrows where the value may be used and is worth passing — a secret is refused against any other site.
• get_secret_linkReturn the dashboard link for one stored secret this account holds, so you can answer "where is my Acme password?" with somewhere to go. **It returns a URL, never a value** — opening it requires the user to be signed in and to confirm who they are, and only their own browser can read what comes back.
• list_connectionsList the saved logins this account already holds, one entry per login: its `id` (name it in a signed-in call as `{ connection: id }`), the site, which account on that site, whether it works right now (`usable`), and when it was made, last used and last checked. **Call this before any task that needs a login, and again whenever you come back to one later.** A `usable` login means the site is already signed in: do not ask the user to sign in, just run the script, naming the id if the site has more than one. Prefer the login you used before over a new one. A login marked `needs_reauth`, `expired` or `logged_out` is not lost. Run the script anyway (name the id if you know it): it pauses with a link, and signing in through that link puts the fresh session back into the SAME id, so you can keep using it. To add a login for a site with none, call `add_connection` — it hands you a sign-in link for the user. `delete_connection` only asks the user to delete one this account already holds.
• add_connectionGet a sign-in link for one site, so the user can sign Bowmark in to it right now, before any run needs it. Pass the site as a domain (`youtube.com`), a URL, or a provider id. **Call this whenever the user asks to log in, sign in, connect or link an account on a site** — never send them to the Bowmark Link extension or the dashboard to do it themselves. It returns `url`, a single-use link that expires (`expiresAt`). Give the user that URL and say which site it is for. On that page they sign in with Bowmark's own browser, or, in desktop Chrome with Bowmark Link installed, press "Use Chrome extension" to send the login that Chrome already holds. Then call `wait_for_sign_in` with the returned `ref`: it answers the moment they finish, and every later run uses the new login. When Bowmark cannot sign in to that site, it says so and returns `sites`, the sites it can sign in to. Tell the user plainly. Do not offer a workaround that asks for their password. A public page on that site still works without a login: `get_library` shows what can read it. To sign back in to a saved login that stopped working, pass its `id` from `list_connections` as `connection`. The fresh session goes into the SAME id.
• wait_for_sign_inWait until the user finishes a sign-in link, so you know the moment they are done without asking them. Pass `ref`: `meta.handoff.ref` from a paused run, or `ref` from `add_connection`. **Call it right after you give the user the link, in the same turn.** Write the link in your reply first, so they can see it while this waits. It holds for up to `waitMs` (default 45000, at most 50000) and answers the moment the sign-in finishes. It returns `state`: • `done`: every site on the link is signed in. Send the SAME script again now (or carry on with the task after `add_connection`). Do not ask the user whether they are done. • `pending`: not yet; `remaining` names the sites still missing. Call it again with the same `ref`. Keep going while the link is live (`expiresAt`, 15 minutes); a person often takes a few minutes. • `cancelled`: the user pressed Cancel. Tell them, and do not re-send the script unless they ask. • `expired`: the link ran out first. Send the SAME script again; it pauses with a fresh link. • `unknown`: no link with that ref on this account. A ref starting `site:` cannot be watched: wait for the user instead. If the user replies while you are waiting, answer them; the link is still live and you can wait again.
• lease_ipSome sites (LinkedIn, marked 📍 in `get_library`) only accept a login from the address it signed in from. A dedicated IP is one address that only this account uses, and once the account holds one, every sign-in link and every later call on that login uses it automatically. Call with no arguments first. If the account already holds one, it says so and nothing is bought. Otherwise it returns `priceCents` and a `message` with the price for `termDays` days in `country` (default US). The price is charged up front and is not refundable. If something must happen first (a card on file, a one-time identity check), `mustFirst` names it with the link that fixes it: give your user that link and stop. **Never buy without asking.** Tell your user the exact price and buy only if they agree, by calling again with `confirmPriceCents` set to the price they agreed to. A live price above that is refused before any charge, and repeating the same call cannot buy two. Pass `another: true` only when your user asked for a second IP.
• delete_connectionStart deleting a saved login by the `id` `list_connections` returned. **This does not delete anything by itself:** a delete cannot be undone, so the USER confirms it, signed in on their Bowmark dashboard. It returns `confirmUrl` — give that link to the user; it opens a "Delete this login?" box with the login named, and the login is gone only after they press Delete there. Nothing you can call completes it for them. Only call this when the user asked to remove a saved login. To sign out of a site, use `logout_connection` instead. Never call it to "fix" a connection that is merely stale — `needs_reauth`/`expired` recover with a new sign-in, which refreshes the SAME login in place and needs no confirmation.
• logout_connectionSign a saved login out by the `id` `list_connections` returned. Bowmark drops the cookies it held, and where the site supports it (`siteLogout: "supported"` in the reply) the session is ended ON THE SITE too — `siteSignedOut: true` means Bowmark checked the site no longer accepts it. The saved login is KEPT, status `logged_out`, so the user can sign back in to the same entry later. Call this when the user asks to sign out of a site. `delete_connection` is the other action: it hands the user a link to forget the entry entirely, which leaves the site session alive.

更新日期：2026-10-29（tools/list 实测）

配置到 Claude / Cursor

{
  "mcpServers": {
    "remote-ai-bowmark-bowmark": {
      "type": "http",
      "url": "https://api.bowmark.ai/mcp/registry"
    }
  }
}