A
licenseA
qualityD
maintenanceEnables AI agents to search hotels, check availability, manage reservations, and book rooms on Booking.com via browser automation.
Last updated
2
15
47
5
MIT
Bowmark
by ai.bowmark
Server Details
Do things on live websites: prices, availability, quotes, bookings, anything behind a form or login.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- bowmark-ai/skill
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.7/5.0
Tool DescriptionsA
Average 4.9/5 across 2 of 2 tools scored.
Server CoherenceA
Disambiguation5/5
The two tools have completely distinct purposes: get_library provides the vocabulary and rules, while run executes scripts using that vocabulary. There is no overlap or ambiguity between them.
Naming Consistency5/5
Both tool names follow a consistent verb_noun pattern (get_library, run), using clear and direct verbs without mixing conventions.
Tool Count3/5
With only two tools, the surface feels minimal but is justified by the focused workflow: retrieve library then execute. It avoids unnecessary tools but could benefit from additional utilities like listing run history.
Completeness4/5
The core workflow (get library, write script, run) is fully covered. The library itself provides all capabilities, so there are no missing operations for the stated purpose. Minor gaps include lack of explicit credential management or run history.
Available Tools
2 toolsget_libraryCheck what can be done on a live website for this taskARead-onlyInspect
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 the full catalog 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 each capability's 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"). Omit it to see everything (the catalog is small). An unrecognized query returns the full catalog rather than an error, so you never dead-end on a near-miss.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | 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. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reinforces readOnlyHint and destructiveHint by stating it is a read-only call with no site touched. Adds behavioral details: returns full catalog on unrecognized query, never dead-ends.
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?
Description is fairly long but well-structured with sections. Every sentence adds value, though could be slightly more concise.
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?
Covers workflow loop (call get_library, write script, run), two-tier capabilities/providers, and references sibling 'run'. Very complete for a tool that returns a library.
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 covers parameter well (100% coverage). Description adds practical guidance on how to formulate query (action vs site), omission behavior, and returns full catalog for unrecognized values.
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?
Clearly states the tool checks what a live website can do, returning a function library. Distinguishes from sibling 'run' which executes scripts.
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?
Explicitly says use 'whenever a task touches a live website' and emphasizes checking is cheap. Provides guidance on query formulation and handling unrecognized queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
runDo the task on the live websites and return the resultAInspect
Executes the task on the real websites (the search, the price check, the availability lookup, the configurator, the booking flow) and returns what came back. Runs a script you authored against the get_library vocabulary, on the live sites, and returns { ok, result, logs, error, ms }. Call get_library FIRST — it gives the exact function names, argument shapes, and return types; this description is the LANGUAGE + how-to (get_library is just the vocabulary).
THE LANGUAGE — plain async JavaScript:
• bowmark is a ready global (no import). Call capabilities off it — await bowmark.<capability>.<method>(...) — always await, they're async.
• Individual sites are callable too, at await bowmark.providers.<provider>.<fn>(...). Use one when you specifically want THAT site; otherwise prefer the capability, which fans out across sites and routes around failures.
• Real control flow: await, if, loops, array methods (map/filter/sort/slice), and Promise.all for fan-out.
• return a value to get it back (JSON-serialized). log(...) for progress lines.
• bowmark is the ONLY I/O — no fetch, process, filesystem, or import/require. Write a plain async body, not a wrapping function.
• Keep scripts small and deterministic — no infinite loops. Runs in a hard sandbox with CPU + memory + wall-clock limits.
SENDING IT: pass the script text as run({ script }) — script is the only argument (there is no site argument; the library exposes every capability under bowmark). result is whatever you returned; logs are your log() lines in order; on a throw/timeout ok:false and error is set.
CHECK status BEFORE ok. It is ok | error | needs_user.
• needs_user means a site needs the USER signed in — it is NOT a failure and NOT something you can fix by editing the script. needs lists the sites; meta.handoff.url is a single-use link that expires (meta.handoff.expiresAt). Give the user that URL, say which sites it covers, and WAIT. When they tell you they're done, send the SAME script again unchanged. Do NOT retry before then — it will stop at the same place and cost another run. Do NOT try to log in yourself, ask them for a password, or work around it with a different site.
• Logged-in runs need a Bowmark API key on the connection; if you get needs_user saying so, tell the user to add one rather than retrying.
trace is the execution trace — every capability you called and the providers it fanned out to under the hood: [{ kind:'capability', capability:'flights', method:'search', ms }, { kind:'provider', capability:'flights', provider:'google_flights', fn:'search', results, status, ms }, …]. The script never visits websites — it calls capabilities that route to providers, and the trace is the receipt.
Composition is the point — call a method MULTIPLE times and combine results. To sweep a date range, call the search per date inside Promise.all and sort/filter the merged array (each flight result carries its date, so you can tell the runs apart). See the get_library examples for the exact shape.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | The JavaScript script body to execute (async, against the `bowmark` global). e.g. `const f = await bowmark.flights.search({from:'SFO',to:'JFK',depart:'2026-09-01'}); return f.sort((a,b)=>a.price-b.price)[0];` |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ms | No | |
| ok | Yes | |
| logs | No | |
| meta | No | |
| error | No | |
| needs | No | |
| result | No | |
| status | No |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses sandbox limitations, I/O restrictions, execution details (CPU/memory limits), trace output, and needs_user handoff flow. Annotations are minimal but description fully compensates.
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?
Well-structured with clear sections, but slightly lengthy due to comprehensive details. Every section adds value, so it's appropriately verbose for the complexity.
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?
Covers all aspects: language, API usage, error handling, handoff flow, composition examples. Despite complexity, the description leaves no gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'script' with full schema coverage. Description adds context that script is the only argument, no site parameter, and provides language semantics and execution model beyond the schema.
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 it executes tasks on real websites, returns results, and distinguishes itself from get_library by explaining it is the execution layer while get_library provides the vocabulary.
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?
Explicitly instructs to call get_library first, explains when to use capabilities vs specific providers, and details how to handle different response statuses (ok, error, needs_user) with no-retry guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityDmaintenanceAutomate web browsing and data extraction by converting live pages into clean Markdown. Execute multi-step workflows and interact with websites using human-like movements.Last updatedMIT
- AlicenseAqualityDmaintenanceEnables AI-powered web browsing automation using Google's Gemini 2.5 Computer Use API. Allows agents to navigate websites, click buttons, fill forms, and extract information through natural language commands with real-time progress tracking.Last updated7MIT
- -license-qualityBmaintenanceEnables autonomous AI agents to perform browser-based tasks like login, form filling, and data extraction via natural language, with pay-per-call billing and on-chain settlement.Last updated1