Skip to main content
Glama

openFlow

by io.github.molkex
OverviewDiscussionsAdmin

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.

HOW TO GET oauth_token: the agent must first run the local grabber on the user's
machine (it opens a native Chrome at accounts.google.com/EmbeddedSetup; the user
logs in and clicks "Принимаю"/Accept):
    npx --yes github:... local_grab   (or: node browser-tools/local_grab.js 9222)
It prints {"email", "oauth_token"}. Pass those here. The oauth_token is SINGLE-USE:
if this call fails, the user must re-login and grab 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.8/5.0
Behavior5/5

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

Goes well beyond annotations by disclosing that the token is single-use, failed calls require a fresh login, successful binds are tied to the key's owner group, worker pickup takes ~30s, and no restart is needed. Also warns that a master token grants full account access. No contradiction with 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?

The description is longer than average but every section earns its place: purpose, token acquisition steps, single-use warning, success behavior, and security boundary. It is well-organized with a clear 'HOW TO GET oauth_token' section and front-loaded purpose.

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?

Provides nearly everything needed to call the tool correctly: how to obtain inputs, what happens on success, timing, failure behavior, and security constraints. The main gaps are the unmentioned reset_day parameter and the absence of any tool response details, though these are partially mitigated by the rich surrounding guidance.

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 description thoroughly explains email and oauth_token, including how to obtain them and the single-use behavior of oauth_token. However, reset_day is completely undocumented, and since schema description coverage is 0%, this is a real gap.

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 verb ('Attach'), a resource ('one of YOUR OWN Google accounts'), and the mechanism ('oauth_token captured on the USER'S OWN machine'). Clearly distinguishes this self-serve onboarding path from server-side browser or SSH approaches.

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 identifies when to use it ('self-serve onboarding path'), how to obtain the required token via the local grabber, and critical constraints: the token is single-use, must never be retried, and should only be used for accounts the caller controls. Also notes that adding an account is always allowed even after quota is spent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All openFlow toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources