PostOnce

connect_account

Read-only

Computes a five-minute browser authorization URL bound to the authenticated profile without connecting or changing an account. The provider is authorized when the user opens the returned URL in their own browser; the account is connected once that flow finishes. Depending on platform, the browser uses provider OAuth or a PostOnce-hosted credential or signer flow, so provider credentials are entered only on that page. Partner accounts may send external_user_id and an allowed redirect_url; after consent the end user is redirected to redirect_url with status, account_id, platform and external_user_id (or error).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "platform": "<platform>"
    },
    "name": "connect_account"
  }
}

Input Schema

Name	Required	Description
`platform`	Yes
`redirect_url`	No	Partner accounts only. Must exactly match one of your allowed redirect URLs.
`idempotency_key`	No
`external_user_id`	No	Partner accounts only. Your own id for the end user connecting the account.

Output Schema

Name	Required	Description
`body`	No	Upstream error details, when available.
`code`	No	Error code when the tool result has isError=true.
`data`	No	Present on successful results; omitted on tool errors.
`meta`	No
`status`	No
`message`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only and non-destructive annotations, it discloses the URL lifetime, authenticated-profile binding, deferred account mutation, required user interaction, platform-dependent OAuth or hosted flows, and where provider credentials are entered. It also explains the post-consent redirect and its status or error information, all consistently with the 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?

It front-loads the operation, expiry, and non-mutating behavior, then proceeds logically through user completion, credential handling, and partner redirects. Although dense, every sentence contributes distinct operational information without filler.

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 security-sensitive connection flow with four flat parameters and an output schema, it covers the authenticated-profile prerequisite, URL lifetime, browser handoff, eventual effect, credential security, and redirect outcomes. The output schema can describe the returned URL structure, leaving undocumented idempotency behavior as only a minor gap.

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 adds platform-dependent flow behavior and explains how `external_user_id` and `redirect_url` participate in the partner flow, including the values supplied after consent. However, `idempotency_key` receives no semantics in either the description or schema, so compensation for the 50% schema coverage is incomplete.

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 sentence precisely states that the tool computes a five-minute browser authorization URL for the authenticated profile, while explicitly distinguishing that operation from connecting or changing an account. This resolves the potentially misleading `connect_account` name and differentiates it from the account-management siblings.

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?

It clearly explains the two-stage flow: this call only produces the URL, the user must open it in their own browser, and the account is connected only after that flow finishes. It also scopes `external_user_id` and `redirect_url` to partner accounts and requires an allowed redirect URL, providing concrete conditions for correct invocation.

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

All PostOnce tools Inspect

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

Need Help?