Skip to main content
Glama

Check what can be done on a live website for this task

get_library
Read-only

Use this whenever a task touches a live website. It answers, definitively and cheaply, whether Bowmark can already DO the thing: look up current prices, check real availability or stock, search a site, get a quote or a fare, drive a configurator, start a booking, or pull anything that only exists behind a form, a filter, or a login.

Checking is cheap, so check. One read-only call, no site is touched, and an unrecognized query returns a one-line index instead of an error, so the check never dead-ends and never costs you an attempt. If nothing fits, you have lost one cheap call and can use your normal approach.

What comes back is the callable function library you write against: the runtime globals (log) PLUS, for each capability your query named, its namespace, TypeScript types, functions, and worked examples. Everything listed is real and callable. The language rules and how to run a script are on the run tool description.

Pass query — what you want to DO ("flights", "price a GPU") or, if you have one in mind, the COMPANY or site ("Kayak", "newegg.com"). A phrase in the user's own words is fine; it is matched against the whole library. You get what you asked about and nothing else. If nothing matches — or you send no query — you get instead a one-line index: pick whichever entry fits and CALL AGAIN with its name to get the types and examples you need to write a script.

Every response is bounded, and it says so when it is a slice. A broad query can match more than one response carries; when that happens the answer opens with a partial-answer line naming what it left out. Read it before concluding anything — absence from a sliced list means nothing, and the fix is one narrower query (a single task, or a single company by name), which always returns that entry in full. Only an answer that does NOT say it is a slice supports the conclusion that a task is uncovered.

Two tiers come back. CAPABILITIES (bowmark.flights.search(...)) are the default and usually what you want: one call fans out across several sites, dedupes, ranks, and routes around a site that's failing. PROVIDERS (bowmark.providers.kayak.search(...)) are the individual sites, callable directly — they appear only when your query NAMED a company, or when the capability has just one provider behind it. A direct provider call gets that site's own raw shape and no failover, so prefer the capability unless you specifically want that site.

Loop: call get_library → write a JS script against the bowmark global → send it to run.

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"). 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.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: it is a cheap call, never touches the site, returns bounded responses with clear slice indicators, and provides a two-tier structure (capabilities vs providers). It explicitly warns about partial answers and how to interpret absence, which goes beyond annotations.

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?

The description is long but each sentence earns its place, providing essential operational details. It is front-loaded with the key instruction ('Use this whenever...') and uses bolded headers and paragraphs for structure. While lengthy, it avoids redundancy and is well-organized for scanning. Not overly wordy despite the complexity of the tool.

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?

Given the tool's complexity and lack of output schema, the description is remarkably complete. It explains response structure (partial answers, slices, tiers), runtime globals, language rules, and how to proceed after the call. It leaves no critical gap for an agent to call it correctly. The only minor omission is not detailing the exact output format of the function library, but that is covered by the 'run' tool reference.

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?

The schema description coverage is 100% (the only parameter 'query' is well-described). The description adds meaning beyond the schema: it explains what to pass (user words, company names), how matching works, and what happens if nothing matches or it is omitted. This adds value over the schema's description, though the schema already defines the parameter well.

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

Purpose5/5

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

The description clearly states what the tool does: it checks a live website for available capabilities and returns a callable function library. It distinguishes itself from siblings like 'run' (which executes scripts) and 'register'. The purpose is specific and actionable, with a clear verb-resource-object structure.

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?

The description provides explicit guidance on when to use this tool ('Use this whenever a task touches a live website') and when not to use it (when nothing fits, use normal approach). It also explains the alternatives: 'run' for executing scripts, and the loop strategy. It covers query construction, fallback behavior, and slicing warnings, leaving no ambiguity about selection.

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.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool has a clearly distinct job: get_library returns capability documentation, run executes scripts against live sites, register creates credentials, and report captures feedback. There is no meaningful overlap or plausible misselection between them.

Naming Consistency4/5

All tool names are lowercase imperative verbs and follow a simple, readable style. The pattern is slightly inconsistent because get_library includes an object while register, report, and run are bare verbs, but the convention is still predictable enough.

Tool Count5/5

Four tools is well-scoped for this server's purpose: discover, execute, authenticate, and give feedback. Each tool earns its place and the count is within the ideal range for a focused MCP server.

Completeness5/5

The core workflow is fully covered: get_library and run form a complete discover-and-execute loop, register handles access and quotas, and report provides a path for missing capabilities. There are no obvious dead ends or missing lifecycle steps for the domain.