Cursor
Grok Bot
Grok
MuseTitle90/100
Check what Bowmark can do for this task
Shorten the title to an action and subject; move usage details into the description.
Description98/100
**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 reference is `get_library({ query: "run guide" })`.
The description explains the capability, when to use it, and what to expect.
Inputs92/100
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
query
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.
Clear enough to supply this argument.
queries
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.
Remove validation rules already expressed in this field’s schema; describe its meaning and usage instead.
minimal
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.
Clear enough to supply this argument.
Annotations75/100
Declare idempotentHint based on the tool’s actual behavior.
{
"readOnlyHint": true,
"openWorldHint": false,
"destructiveHint": false
}Output schema0/100
No output schema is declared. Add one for structured results so clients can interpret returned fields.
Not declared