Skip to main content
Glama

Manage Social OAuth & BYOK Accounts

accounts_manage
Idempotent

List connected social accounts, initiate 1-click Managed OAuth 2.0 flows (connect_oauth), vault custom Bring-Your-Own-Keys (connect_byok) with zero markup and AES-256-GCM encryption, run live upstream API token health checks (account_health), or disconnect accounts across 18+ platforms. Use this tool whenever you need to link a new social network, verify OAuth token validity and latency, or inspect which platforms are ready for publishing. Returns account metadata, 1-click authorizationUrl links, or live latency/health diagnostics; if the workspace connection quota is full, returns a structured PLAN_CONNECTION_LIMIT_REACHED upgrade prompt.

Input Schema

NameRequiredDescriptionDefault
actionYesAccount operation: 'list' connected accounts, 'connect_oauth' to get a 1-click OAuth 2.0 authorization URL, 'connect_byok' to store custom API keys/tokens encrypted with AES-256-GCM ($0 markup), 'account_health'/'health_check' to verify live upstream token validity, or 'disconnect' to remove an account.
platformNoTarget social, blog, or messaging platform slug (e.g. 'x', 'linkedin', 'bluesky', 'instagram', 'threads', 'youtube', 'tiktok', 'reddit'). Required for 'connect_oauth' and 'connect_byok'.
returnToNoconnect_oauth: where to send the user after connecting (relative path, agent deep link like cursor://, or an https origin registered in your OAuth client redirect_uris).
usernameNoAccount handle, username, Bluesky ATProto handle (e.g. 'brand.bsky.social'), or Mastodon instance handle associated with the social account.
accountIdNoConnected social account identifier (e.g. 'acc_x_byok_01'). Required when `action` is 'disconnect' and optional filter for 'account_health'.
profileIdNoBrand profile identifier (e.g. 'prof_allometrik') that owns or filters the social account connections.
accessTokenNoBYOK OAuth 2.0 Bearer access token, OAuth 1.0a access token, Telegram Bot token, or Discord Webhook URL encrypted at rest.
refreshTokenNoOptional OAuth 2.0 refresh token or OAuth 1.0a access token secret used for automatic token rotation and health recovery.
customClientIdNoBYOK OAuth App Client ID, API Key, Bot ID, or Bluesky identifier encrypted at rest with AES-256-GCM in the Nuntior Vault (0% platform markup).
returnClientIdNoconnect_oauth: your DCR OAuth client_id, used to allowlist an https returnTo.
customClientSecretNoBYOK OAuth App Client Secret, API Key Secret, or Bluesky App Password encrypted at rest with AES-256-GCM in the Nuntior Vault.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / returnClientId
      Added value: +{
      +  "description": "connect_oauth: your DCR OAuth client_id, used to allowlist an https returnTo.",
      +  "type": "string"
      +}
    • addedInput schema / properties / returnTo
      Added value: +{
      +  "description": "connect_oauth: where to send the user after connecting (relative path, agent deep link like cursor://, or an https origin registered in your OAuth client redirect_uris).",
      +  "type": "string"
      +}
  2. Changed11 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / accessToken / description
      Previous value: -"Access token, Bot token, or Webhook URL"New value: +"BYOK OAuth 2.0 Bearer access token, OAuth 1.0a access token, Telegram Bot token, or Discord Webhook URL encrypted at rest."
    • addedInput schema / properties / accountId / description
      Added value: +"Connected social account identifier (e.g. 'acc_x_byok_01'). Required when `action` is 'disconnect' and optional filter for 'account_health'."
    • addedInput schema / properties / action / description
      Added value: +"Account operation: 'list' connected accounts, 'connect_oauth' to get a 1-click OAuth 2.0 authorization URL, 'connect_byok' to store custom API keys/tokens encrypted with AES-256-GCM ($0 markup), 'account_health'/'health_check' to verify live upstream token validity, or 'disconnect' to remove an account."
    • changedInput schema / properties / customClientId / description
      Previous value: -"BYOK OAuth App Client ID / Bot ID / Handle (encrypted via AES-256-GCM)"New value: +"BYOK OAuth App Client ID, API Key, Bot ID, or Bluesky identifier encrypted at rest with AES-256-GCM in the Nuntior Vault (0% platform markup)."
    • changedInput schema / properties / customClientSecret / description
      Previous value: -"BYOK OAuth App Secret / App Password (encrypted via AES-256-GCM)"New value: +"BYOK OAuth App Client Secret, API Key Secret, or Bluesky App Password encrypted at rest with AES-256-GCM in the Nuntior Vault."
    • addedInput schema / properties / platform / description
      Added value: +"Target social, blog, or messaging platform slug (e.g. 'x', 'linkedin', 'bluesky', 'instagram', 'threads', 'youtube', 'tiktok', 'reddit'). Required for 'connect_oauth' and 'connect_byok'."
    • changedInput schema / properties / platform / enum
      Previous value: -[
      -  "x",
      -  "linkedin",
      -  "instagram",
      -  "facebook",
      -  "threads",
      -  "tiktok",
      -  "youtube",
      -  "bluesky",
      -  "mastodon",
      -  "farcaster",
      -  "reddit",
      -  "pinterest",
      -  "google_business",
      -  "telegram",
      -  "discord",
      -  "ghost",
      -  "wordpress",
      -  "webflow"
      -]New value: +[
      +  "x",
      +  "linkedin",
      +  "bluesky",
      +  "instagram",
      +  "facebook",
      +  "threads",
      +  "tiktok",
      +  "youtube",
      +  "reddit",
      +  "pinterest",
      +  "mastodon",
      +  "telegram",
      +  "discord",
      +  "google_business",
      +  "ghost",
      +  "wordpress",
      +  "webflow",
      +  "whatsapp"
      +]
    • addedInput schema / properties / profileId / description
      Added value: +"Brand profile identifier (e.g. 'prof_allometrik') that owns or filters the social account connections."
    • changedInput schema / properties / refreshToken / description
      Previous value: -"Refresh token or OAuth 1.0a token secret"New value: +"Optional OAuth 2.0 refresh token or OAuth 1.0a access token secret used for automatic token rotation and health recovery."
    • addedInput schema / properties / username / description
      Added value: +"Account handle, username, Bluesky ATProto handle (e.g. 'brand.bsky.social'), or Mastodon instance handle associated with the social account."
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare mutability, open-world scope, and non-destructiveness, but the description adds genuinely useful behavior: 1-click authorizationUrl output, AES-256-GCM vaulting with zero markup, live latency/health diagnostics, and a specific failure path (PLAN_CONNECTION_LIMIT_REACHED quota prompt). It doesn't cover permission scopes required per platform, which is the main remaining gap for a multi-mode write tool.

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?

Purpose is front-loaded with the list action, followed by usage and return-value sentences, so the structure is easy to scan. The first sentence is very dense with parenthetical action names and marketing language ('zero markup', 'AES-256-GCM') that somewhat inflates length, but nothing is wasted outright.

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 an 11-parameter, action-dispatch tool with no output schema, the description covers what each mode returns (account metadata, authorizationUrl, latency/health diagnostics, quota error) and when to reach for it. Missing only per-action parameter mapping and platform-specific auth prerequisites, which keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every one of the 11 parameters is already documented with examples and enum values; the description's job here is minimal. It adds a little routing context (connect_oauth produces authorizationUrl, returnTo matters for redirects) but does not explain which params pair with which action beyond what the schema already states. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates concrete operations (list, connect_oauth, connect_byok, account_health, disconnect) with specific verbs and resources across platforms, so an agent knows exactly what the tool does. However, it never distinguishes itself from same-domain siblings like account_register and account_status, which plausibly overlap with 'list connected accounts', so sibling differentiation is absent.

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?

The explicit 'Use this tool whenever you need to link a new social network, verify OAuth token validity and latency, or inspect which platforms are ready for publishing' gives clear triggering conditions. It stops short of naming when NOT to use it or pointing to alternative tools (e.g., account_register for first-time setup), leaving that inference to the agent.

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.

Resources