Skip to main content
Glama

Ask the user to set a login Bowmark will need

request_secret
Idempotent

Create a named, empty slot for a secret and get back a link the user opens to fill it in. They type the value on a Bowmark page and choose how long it lives, from 5 minutes to never. It is encrypted in their own browser before it leaves, so nothing on the way — this connection included — ever sees it.

Give the user the link. Never ask them to type a password, API key or one-time code to you. A secret in this conversation is in your context, in the transcript and in the logs.

Name it for the person, not for your script. The name you pass is the heading on the page they open and the row they see in their secret list months later, so make it <site>_<what it is>: letterboxd_password, stripe_api_key, acme_totp_seed. A run id, a timestamp, a uuid or a bare password is refused.

Call list_secrets first: if the name already exists and is set, use it instead. name is lowercase letters, digits, _, . and -. hosts narrows where the value may be used and is worth passing — a secret is refused against any other site.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesLowercase name, `<site>_<what it is>` — `letterboxd_password`, `stripe_api_key`, `acme_totp_seed`. Letters, digits, _ . - only. THE USER READS THIS: it is the heading on the page they open and the row in their credential list months later, so use words, never a run id, a timestamp or a bare `password`.
typeYesWhat kind of value the person will be asked for.
hostsNoHosts the value may be used against, e.g. ["acme.com"]. Refused elsewhere.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Discloses crucial behaviors beyond annotations: browser-side encryption, transcript/log exposure, refusal of non-human-readable names, and host-slot enforcement. None of these are visible in the schema or annotations.

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?

Front-loads the core mechanism, then uses bold directives for the two most safety-critical instructions. Despite length, every sentence earns its place by adding security, naming, or usage guidance.

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?

Provides outcome (a link), user journey, lifetime range, preconditions, validation rules, and failure behavior. No output schema exists, but the return value is described sufficiently for 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 already covers all three parameters, so the baseline is 3. The description adds meaning for name (user-facing heading, months-later list row, naming refusals) and hosts (worth passing, refused elsewhere), though type semantics remain only in 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?

States a specific action: create a named empty secret slot and return a user-facing fill-in link. This clearly distinguishes it from lookup/listing siblings like list_secrets and get_secret_link.

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

Usage Guidelines4/5

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

Gives explicit preconditions: call list_secrets first and reuse an existing set secret, and instructs the agent to hand the link to the user rather than collect the secret. It does not explicitly compare with get_secret_link, so it loses a point.

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.