Skip to main content
Glama

add_account_token

Attach one of YOUR OWN Google accounts to the pool using an oauth_token captured on the USER'S OWN machine (password/2FA never leave it). This is the self-serve onboarding path — no server-side browser, no SSH.

PREFERRED PATH — no oauth_token handling at all: call flow_status; its
`next_step.command` holds a PERSONAL one-line command per OS (mac / linux / win) with
the owner's ticket inside. RUN IT YOURSELF in the user's terminal. The script submits
the token to the server by itself and prints "Готово — аккаунт ... подключён"; you do
NOT call add_account_token afterwards. (The same command is shown to the user in the
cabinet: https://openflowmcp.com/account#accounts.) Node 22+ is the only requirement.

FALLBACK (only if flow_status has no command, or the script says it could not submit
automatically) — run the generic command, which has no ticket and just prints a line:

    curl -sL https://openflowmcp.com/onboard_local.js | node

Windows PowerShell:

    irm https://openflowmcp.com/onboard_local.js -OutFile o.js; node o.js

It opens the user's own Chrome at accounts.google.com/EmbeddedSetup. Tell them to log
in and press Accept, then wait until the page hangs on a spinner (normal, the token is
already issued), then go BACK to the terminal window running the script and press
Enter — the script grabs the token only after Enter, it does not do it by itself. Do
not close the browser window before that. The script prints ONE JSON line: {"status":200,"oauth_token":...,
"email":...}; with a personal command it also adds "submitted":true, which means the
account is already connected and you are done. Without "submitted":true, pass
oauth_token and email here.

If it prints "need_email": true, the account address could not be read off the page —
ask the user which Google account they just signed into and pass that as `email`, or
re-run with ONBOARD_EMAIL=them@gmail.com in front of the command.

The oauth_token is SINGLE-USE: if this call fails, the user must log in again for a
FRESH token — never retry the same one.

On success the account is bound to YOUR key's owner group and the worker picks it up
within ~30s (no restart). Adding an account is always allowed — even for a key that
has already spent its free quota, since that is a prerequisite, not a reward.

Only onboard accounts YOU control — a master token grants full account access.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYes
reset_dayNo
oauth_tokenYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover safety hints (readOnly=false, idempotent=false, openWorld=true), and the description adds substantial behavior beyond them: the token is SINGLE-USE and must never be retried, the account binds to the key's owner group and is picked up by a worker within ~30s without restart, adding is always permitted even after free quota is spent, and a master token grants full account access. It also documents failure and edge paths ('need_email', 'submitted':true).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the PREFERRED/FALLBACK headings give useful structure, but at ~350 words this is far longer than needed — it embeds runbook content such as OS-specific curl/irm commands and a literal success string for a separate script, which does not help an agent select or invoke this specific tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, non-idempotent, 0%-schema-coverage tool with no output schema, the description is thorough: it explains the return JSON line, the 'submitted' flag, the 'need_email' branch, propagation timing, and permissions. The only real gap is the undocumented reset_day parameter.

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?

With 0% schema coverage the description must carry the burden, and it explains email (the Google address just signed into, with a recovery path if it cannot be read) and oauth_token (single-use, obtained from the local script) in rich detail. However reset_day is never mentioned anywhere in the description, leaving one of three parameters fully undocumented.

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 opening states a specific verb+resource: 'Attach one of YOUR OWN Google accounts to the pool using an oauth_token'. It further scopes it as 'the self-serve onboarding path — no server-side browser, no SSH', which cleanly separates it from all generation/list siblings and from the flow_status workflow it references.

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 when-to-use and when-not: the PREFERRED PATH is to call flow_status and run its command yourself and NOT call this tool afterwards; this tool is the FALLBACK only if flow_status has no command or the script fails to submit. The distinction between the two paths and the preconditions ('Node 22+', 'no ticket') is fully spelled out.

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.