Skip to main content
Glama

Create a free Bowmark account for more calls

register

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentNoOPTIONAL 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.
emailNoOPTIONAL 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.
newsletterNoOPTIONAL, 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.
promotionsNoOPTIONAL, 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

TableJSON Schema
NameRequiredDescriptionDefault
okYes
emailNo
errorNo
apiKeyNo
reasonNo
messageNo
claimUrlNo
accountIdNo
activeNowNo
keyPrefixNo
signInUrlNo
newsletterNo
promotionsNo
claimExpiresAtNo
freeCallsPerMonthNo

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.

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.