Skip to main content
Glama

Check what Bowmark can do for this task

get_library
Read-only

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 is narrower: it works where a purpose-built provider exists for that site or the caller has a saved connection there, not by default.

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 have lost one cheap call and can 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

TableJSON Schema
NameRequiredDescriptionDefault
queryNoOptional, 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.
queriesNoOptional. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"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 returns the one-line index rather than an error, and so does omitting it."New value: +"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."
  2. Changed1 schema field changed
    • addedInput schema / properties / queries
      Added value: +{
      +  "description": "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.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"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. A rough guess is always safe: a value that matches nothing returns the one-line index rather than an error, and so does omitting it."New value: +"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 returns the one-line index rather than an error, and so does omitting it."
  4. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"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\"). A rough guess is always safe: a value that matches nothing returns the one-line index rather than an error, and so does omitting it."New value: +"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. A rough guess is always safe: a value that matches nothing returns the one-line index rather than an error, and so does omitting it."
  5. Changed1 schema field changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  6. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"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\"). A rough guess is always safe: a value that matches nothing returns the one-line index of the whole library rather than an error, and so does omitting it."New value: +"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\"). A rough guess is always safe: a value that matches nothing returns the one-line index rather than an error, and so does omitting it."
  7. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Optional. 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\"). Omit for the full catalog; an unrecognized value also returns the full catalog, so a rough guess is always safe."New value: +"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\"). A rough guess is always safe: a value that matches nothing returns the one-line index of the whole library rather than an error, and so does omitting it."
  8. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Optional. What you want to do (\"flights\", \"price a GPU\"), or a company/site if you specifically want one (\"Kayak\", \"newegg.com\"). Omit for the full catalog; an unrecognized value also returns the full catalog."New value: +"Optional. 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\"). Omit for the full catalog; an unrecognized value also returns the full catalog, so a rough guess is always safe."
  9. Added

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description is consistent with all three ('One read-only call, no site is touched'). Beyond that it discloses real behavioral quirks the annotations cannot: a non-matching query says so rather than erroring, answers can be sliced (so absence from a sliced list means nothing), and the index vs. detail levels behave differently. That is exactly the added context the dimension rewards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the primary trigger and organized with bold sub-headings, and the closing loop ('call get_library -> write a JS script -> send it to run') is a useful anchor. It is long for a two-parameter lookup and repeats the hostname guidance already present in the schema, so not every sentence strictly earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain returns — and it does: the function library with capabilities that fan out across sites, plus site-specific providers when a company was named, and the index/detail distinction. Combined with the error and slicing behavior, an agent has everything needed to call this correctly and interpret the answer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: the hostname rule (only a hostname settles coverage; strip URL path/params) and the batching semantics for `queries` (one per part, max 6, `query` folded in). Some of this is duplicated verbatim in the schema descriptions, which caps the score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete job — it 'answers whether Bowmark can already DO the thing' and returns 'the function library you write against' with named capabilities like `bowmark.flights.search(...)`. It also separates itself from siblings by naming the `run` tool and the get_library -> script -> run loop. The opening line, however, leads with usage ('Use this whenever a task touches a live website') rather than what the tool returns, so the actual purpose only surfaces in the fourth paragraph.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use is given twice (live-website tasks, and questions about how to write/run a Bowmark script), plus an explicit narrowing condition — 'Behind a LOGIN is narrower' and it works only where a purpose-built provider or saved connection exists. It also justifies the call ('checking is cheap') and states the fallback ('you can use your normal approach'), leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.