Skip to main content
Glama
Sign In

Postproxy

by dev.postproxy
OverviewDiscussionsAdmin

profile_groups_initialize_connection

Generate a URL to connect a new social media profile to a profile group (initiates the OAuth/connect flow). The returned URL should be opened by the user to complete the connection. For whatsapp, optionally pass onboarding ('api' or 'business_app'); when omitted the connect page asks the user where their number lives. For instagram, optionally pass onboarding 'facebook' to connect through Facebook Login (an Instagram professional account linked to a Facebook Page the user manages) instead of the default Instagram Login. Bluesky and Telegram need credentials, so they are connected in the Postproxy web app rather than here.

Input Schema

NameRequiredDescriptionDefault
platformYesPlatform to connect (e.g. 'instagram', 'linkedin', 'bluesky', 'telegram')
onboardingNoInstagram and WhatsApp only. Instagram: 'instagram' (default) connects with Instagram Login; 'facebook' connects with Facebook Login, for an Instagram professional account linked to a Facebook Page the user manages — either way the profile is platform 'instagram', and reconnecting with the other method updates the existing profile in place. WhatsApp: 'business_app' keeps the number in the WhatsApp Business app on a phone (coexistence: QR scan, up to 6 months of chats imported, no group chats through the API); 'api' moves it to the Cloud API only (Twilio/360dialog/own Meta setup or a fresh number; not usable in the app afterwards). Omit to let the user choose on the connect page.
profile_group_idYesProfile group ID (hashid) to connect a profile to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / onboarding / description
      Previous value: -"WhatsApp only. 'business_app' keeps the number in the WhatsApp Business app on a phone (coexistence: QR scan, up to 6 months of chats imported, no group chats through the API); 'api' moves it to the Cloud API only (Twilio/360dialog/own Meta setup or a fresh number; not usable in the app afterwards). Omit to let the user choose on the connect page."New value: +"Instagram and WhatsApp only. Instagram: 'instagram' (default) connects with Instagram Login; 'facebook' connects with Facebook Login, for an Instagram professional account linked to a Facebook Page the user manages — either way the profile is platform 'instagram', and reconnecting with the other method updates the existing profile in place. WhatsApp: 'business_app' keeps the number in the WhatsApp Business app on a phone (coexistence: QR scan, up to 6 months of chats imported, no group chats through the API); 'api' moves it to the Cloud API only (Twilio/360dialog/own Meta setup or a fresh number; not usable in the app afterwards). Omit to let the user choose on the connect page."
    • changedInput schema / properties / onboarding / enum
      Previous value: -[
-  "api",
-  "business_app"
-]New value: +[
+  "api",
+  "business_app",
+  "instagram",
+  "facebook"
+]
  2. Changed3 schema fields changed
    • removedInput schema / properties / app_password
      Removed value: -{
-  "description": "Bluesky app password (bsky.app/settings/app-passwords). Required for bluesky.",
-  "type": "string"
-}
    • removedInput schema / properties / bot_token
      Removed value: -{
-  "description": "Telegram bot token from @BotFather. Required for telegram.",
-  "type": "string"
-}
    • removedInput schema / properties / identifier
      Removed value: -{
-  "description": "Bluesky handle (e.g. yourname.bsky.social). Required for bluesky.",
-  "type": "string"
-}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already disclose non-read-only, openWorld, non-idempotent behavior, so the bar is lower, yet the description still adds real context: the output is a URL the user must open, and it details platform-specific connect flows (WhatsApp api/business_app coexistence semantics, Instagram Facebook Login vs default). It doesn't mention auth requirements or rate limits, so not a perfect score.

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?

It is front-loaded with purpose and the URL behavior before diving into per-platform parameter nuances, which is the right ordering. The platform-specific sentences are dense but each carries distinct information; slightly long, but nothing is pure filler.

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 mutation-style, openWorld tool with no output schema, the description adequately explains what is produced (a connect URL), the required user follow-up, and per-platform coverage limits. Auth expectations and error/expiry behavior of the URL are the only notable gaps.

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% and the onboarding enum is documented in the schema in more detail than the description provides (coexistence, Twilio/360dialog, etc.), so the description largely restates structured data. The note that omitting onboarding lets the connect page ask the user adds minor value, consistent with a baseline 3.

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 description opens with a specific verb+resource: 'Generate a URL to connect a new social media profile to a profile group,' and parenthetically clarifies the mechanism ('initiates the OAuth/connect flow'). Combined with the returned-URL behavior, an agent can immediately distinguish this from list/manage siblings like profile_groups_list or profiles_list.

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?

It states the trigger (connecting a new profile) and the user action that follows (open the returned URL). It also provides meaningful exclusions: Bluesky and Telegram 'are connected in the Postproxy web app rather than here,' steering the agent away for those platforms. It stops short of naming a same-purpose alternative tool, so it isn't a full 5.

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

All Postproxy 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