Check what Bowmark can do for this task
get_libraryUse 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 touched; a match-nothing query says so, never an error. 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 reference is get_library({ query: "run guide" }).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional, but pass one — it decides how much detail comes back. What the user wants to do, in their words ("flights", "price a GPU", "book a table", "check stock"), or a company/site if they named one ("Kayak", "newegg.com"). If they supplied only a URL, pass its hostname rather than the full URL or its query parameters — and a HOSTNAME is worth passing even for a site you expect nothing to exist for, because that is what makes Bowmark look for the site's own tools. A rough guess is always safe: a value that matches nothing says so and what to try next rather than erroring, and omitting it returns the one-line index. | |
| minimal | No | Optional. `true` answers only whether `query` is covered, in one line — no types, no examples, no fallback tools. For a quick coverage check, not for writing a script against the result. | |
| queries | No | Optional. Several lookups in ONE call, one per part of the task: `["amazon", "youtube"]`, `["flights", "hotels in Lisbon"]`. Each entry is written exactly like `query` and answered exactly as `query` alone would be, in its own section. Use this instead of calling get_library once per part. At most 6; a `query` passed alongside is folded in. |