A
licenseA
qualityB
maintenanceEnables AI agents to search hotels, check availability, manage reservations, and book rooms on Booking.com via browser automation.
2
15
33
5
MIT
Bowmark
by ai.bowmark
Server Details
Do things on live websites: prices, availability, quotes, bookings, anything behind a form or login.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- bowmark-ai/skill
- GitHub Stars
- 0
Available Tools
4 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 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.
ParametersJSON 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"). 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.
registerCreate a free Bowmark account for more callsAInspect
Creates a free Bowmark account and returns an API key. Call it when a run is refused for hitting the anonymous limit, when you expect to make more than a handful of calls, or any time the user says they want an account.
Every argument is optional. register({}) is a complete, valid call and returns a working key. Do NOT stop to ask the user for anything before calling this — there is nothing required to ask for.
WHAT IT BUYS: anonymous callers share one small daily allowance per IP address with everything else behind it. A registered account gets its own monthly allowance, an order of magnitude larger. The response says both numbers. Where the connection allows it the new allowance applies IMMEDIATELY, with no configuration change — activeNow: true in the response means your very next run is already on it.
email is OPTIONAL and no key depends on it — it is not a credential, and nothing you do with the API authenticates with it. But passing one CREATES A BOWMARK SIGN-IN for that address, so the person can sign in at bowmark.ai with an emailed code and manage the account without keeping any link. Pass it only if the user actually gave you one. Never invent one and never pass a placeholder — that creates a sign-in for somebody else's mailbox.
IF YOU PASS AN email, TELL YOUR USER THIS: that address is subscribed to occasional Bowmark product and changelog email by default. Pass newsletter: false to decline, and say so plainly rather than deciding for them — every message carries a one-click unsubscribe either way. With no email there is nothing to subscribe and nothing to mention.
promotions is a SEPARATE consent and is OFF unless you set it. Only set it if the user has actually said yes to promotional email. Do not infer consent from enthusiasm, and do not set it to be helpful.
AFTER IT RETURNS: show the user apiKey. It is returned exactly once and cannot be recovered — tell them to save it and to add it to their Bowmark MCP config as Authorization: Bearer <key> so it works from every future session. Do not put the key in a file, a commit, or anywhere it outlives the conversation.
HOW THEY REACH THE ACCOUNT AS A PERSON. If signInUrl came back, that is the way in: they sign in there with the email you passed, Bowmark sends a code, and they land in this account. Nothing to save. claimUrl is then only a backup for a wrong address. If signInUrl is null, claimUrl is the ONLY door — show it, and say claimExpiresAt is the date it stops working, because after that they can use the key but never manage or revoke the account.
Re-registering is not how you get a second key: an address that already has an account is refused, and there is a per-network cap. If you already hold a key, present it instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | OPTIONAL free-text name for this account, so the user can tell their keys apart later ("claude-code on my laptop", "research-bot"). Purely a label. | |
| No | OPTIONAL contact address. It is NOT an API credential — no key depends on it — but passing one CREATES A BOWMARK SIGN-IN for that address, so the user can sign in with an emailed code and manage the account. Pass it only if the user supplied one; omit it entirely otherwise. Never invent, guess, or placeholder this — an address you made up is somebody else's mailbox. | ||
| newsletter | No | OPTIONAL, and it DEFAULTS TO TRUE — occasional product and changelog email to the address you passed. Set false to decline. It does nothing at all when no `email` is given, since there is no address to reach. If you are passing an email, tell your user it subscribes them and that you can decline for them. | |
| promotions | No | OPTIONAL, and a SEPARATE consent from `newsletter`. Set true ONLY if the user explicitly agreed to promotional email. Defaults to false. Do not infer this. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| No | ||
| error | No | |
| apiKey | No | |
| reason | No | |
| message | No | |
| claimUrl | No | |
| accountId | No | |
| activeNow | No | |
| keyPrefix | No | |
| signInUrl | No | |
| newsletter | No | |
| promotions | No | |
| claimExpiresAt | No | |
| freeCallsPerMonth | No |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (only readOnlyHint=false and destructiveHint=false), so the description carries the full burden — and it delivers. It discloses side effects (passing email 'CREATES A BOWMARK SIGN-IN'), consent semantics (newsletter defaults true, promotions defaults off and must never be inferred), irrecoverability of the API key, per-network caps, re-register refusal, and the signInUrl/claimUrl access paths. No contradiction with annotations; readOnlyHint=false correctly aligns with the create-account mutation.
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 (~350 words) but every section addresses a real correctness or safety concern, and it is front-loaded with purpose before usage before parameters. Bold headers ('WHAT IT BUYS', 'AFTER IT RETURNS', 'HOW THEY REACH THE ACCOUNT AS A PERSON') give the agent navigable scannability. Minor redundancy in 'Do NOT stop to ask the user for anything' is defensible as emphasis for an autonomous agent.
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?
Exceptionally complete for a tool with this complexity: 4 optional params, critical side effects (sign-in creation), consent handling, an irrecoverable API key, account-access flows (signInUrl/claimUrl/claimExpiresAt), and rate caps. It covers pre-conditions, the call pattern, per-parameter consent rules, post-call steps, and boundaries. The output schema exists so return-value handling is already covered.
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 coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema: the 'Every argument is optional; register({}) is a complete, valid call' pattern, the non-credential nature of email, the 'never invent one' guardrail, and the separation of newsletter vs promotions consent. Some of this duplicates the schema's own rich parameter descriptions, but the description frames it as operational guidance an agent acting autonomously needs.
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?
Opens with a specific verb+resource+return: 'Creates a free Bowmark account and returns an API key.' It immediately distinguishes from the sibling `run` by telling the agent to call it when 'a `run` is refused for hitting the anonymous limit,' and the mention of 'get a second key' also separates it from get_library. Unambiguous scope.
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?
Provides explicit trigger conditions ('Call it when a run is refused for hitting the anonymous limit, when you expect to make more than a handful of calls, or any time the user says they want an account') and an explicit when-not ('Re-registering is not how you get a second key... If you already hold a key, present it instead'). Both inclusion and exclusion criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reportReport what Bowmark could not do for this taskAInspect
Record what was missing, wrong, or incomplete so Bowmark can build it. Pass the runId returned by run when this report is about a run; omit it when get_library did not cover the task. This records feedback only and does not retry a run.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| runId | No | Optional `runId` returned by `run` for the result you are reporting. | |
| report | Yes | What Bowmark could not do or returned incorrectly. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no informative annotations, the description usefully discloses that this records feedback only and has no retry behavior. It could add detail about side effects or permissions, but it provides materially more transparency than the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences front-load the purpose, then provide the runId conditional and a no-retry warning. There is no filler or repetition of schema text.
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?
For a low-complexity 2-parameter tool with an output schema, the description covers purpose, parameter conditions, and behavioral boundaries. Nothing essential is missing for correct invocation.
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 coverage is 100%, so a baseline of 3 applies. The description adds value by explaining when runId should be present or omitted, which goes beyond the schema's generic 'Optional runId returned by run'.
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?
States a specific action ('Record what was missing, wrong, or incomplete') and a clear resource (feedback for Bowmark to build). The title and description together distinguish this from run and get_library by framing it as a feedback-only operation.
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?
Gives explicit conditions: pass runId when reporting on a run, omit it when get_library did not cover the task, and do not use this to retry a run. This directly routes an agent among the sibling tools and states a when-not.
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 resultADestructiveInspect
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.
• Standard JavaScript built-ins are there (JSON, Math, Date, RegExp, Intl, Promise), plus URL and URLSearchParams — use them to resolve a relative link against the page it came from and to build query strings. Nothing else from the Web platform exists: no fetch, setTimeout, TextEncoder or crypto.
• 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.
Your own tool-call budget is tighter than you'd guess, and it decides how many calls fit in one script. Most MCP clients time a single tool call out at around 55 seconds, and ONE ordinary capability call already spends 30-55 seconds of that fanning out to live sites — see COMPOSITION below before calling a second capability in the same script.
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 | partial | needs_user.
• partial means the script RAN and result is real and usable, but some of what it called never answered — so the result is narrower than what you asked for. ok is still true; this is not a failure. incomplete.summary says what happened in one sentence, incomplete.failures names each call that threw and what the site said, and incomplete.degraded names each call that answered while reporting its OWN results thin. You MUST say so when you present the result: name what was missed, and do not describe it as complete, exhaustive, or 'all' of anything. A partial you report as whole is a wrong answer, not a slightly smaller right one.
• Before you conclude a partial is final, check incomplete.failures[].fixable. fixable: true means YOUR ARGUMENT was rejected, not the site — the error text names what that function actually takes, so re-read it in get_library, fix the argument and run again; that recovers the whole answer. For any other failure re-running usually returns the same thing.
• 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 MEANS PARALLEL, NOT SEQUENTIAL. Default to ONE capability call per script — most already spend 30-55 seconds of your own ~55-second tool-call budget on their own, so a second call made AFTER the first routinely never returns before your client gives up, and the script errors with nothing to show for either call. If you genuinely need several, run them TOGETHER inside Promise.all — in parallel they cost about what one call costs, not the sum of them — and never call them one after another. 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. If even one call will not fit your budget, narrow the query (fewer dates, a single site instead of a fan-out) or split the work across separate turns — do not compose more into one script to make it fit.
SOME capabilities return their rows alongside a warnings array — { flights, warnings }, { hotels, warnings }, { cars, warnings }. Others return a bare array. The signature in get_library tells you which; go by it rather than assuming. Where there IS a warnings array it names any site dropped from the fan-out, and the rows themselves look identical with or without it. Read it, and pass on anything it says rather than quoting a 'cheapest' that only ranks the sites that happened to answer. Dropping warnings from what you return does not hide it — the run comes back status: 'partial' regardless, because the runtime counts what your script CALLED, not what it chose to report.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | The JavaScript script body to execute (async, against the `bowmark` global). e.g. `const { flights, warnings } = await bowmark.flights.search({from:'SFO',to:'JFK',depart:'2026-09-01'}); return { best: flights.sort((a,b)=>a.price-b.price)[0], warnings };` |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| ms | No | |
| ok | Yes | |
| logs | No | |
| meta | No | |
| error | No | |
| needs | No | |
| runId | No | |
| result | No | |
| status | No | |
| incomplete | No |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses far beyond annotations: sandbox limits, no fetch/import/process, bowmark as only I/O, statuses (ok/error/partial/needs_user), fixable failures, handoff URLs, API key requirements, trace receipts, and warnings. The destructiveHint=true is consistent with executing real-site actions like booking flows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but tightly structured with bold headers and bullets, front-loading the core purpose and return shape. Each section addresses a real failure mode, budget constraint, or usage nuance, so every sentence 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?
Given the complexity of executing arbitrary scripts against live sites, the description covers execution semantics, failure modes, output interpretation, warnings, and interaction with get_library. Nothing essential for correct invocation is missing.
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?
Schema coverage is 100%, and the description adds extensive meaning to the script parameter: it is the only argument, no site argument exists, the body must be async, bowmark is global, return values are JSON-serialized, and composition constraints apply. This far exceeds the schema description.
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 states a specific action: executing user-authored scripts against the bowmark capability vocabulary on live websites, and returns a defined object shape {ok, result, logs, error, ms}. It clearly distinguishes itself from get_library by framing get_library as the vocabulary and this tool as the execution runtime.
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 guidance is abundant: call get_library FIRST, default to one capability call per script, use Promise.all for parallel composition, narrow the query or split work if budget is tight, and how to handle partial/needs_user results. This leaves no ambiguity about when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
No tool schema history has been recorded yet.
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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 Connectors
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Turn any webpage into a structured action manifest — clickable, fillable, submittable elements.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAutomate web browsing and data extraction by converting live pages into clean Markdown. Execute multi-step workflows and interact with websites using human-like movements.MIT
- 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.7MIT
- FlicenseNot gradedqualityBmaintenanceEnables 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.2-
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.